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AESTRACT 


This  thesis  presents  a  detailed  design  and 
implementation  of  a  memory  manager  for  a  kernel  technology 
based  secure  archival  storage  system  (SAS3),  The  memory 
manager  is  part  of  the  noa-distributed  portion  of  the 
Security  Kernel,  and  is  solely  responsible  for  the  proper 
management  of  both  the  main  memory  (random  access)  and  the 
secondary  storage  (direct  access)  of  the  system.  The  memory 
manager  is  designed  for  implementation  on  the  ZILOG  Z6CPC 
microprocessor  in  a  multi-processor  environment.  The  loop 
free  design  structure,  based  upon  levels  of  abstraction,  and 
a  segment  aliasing  scheme  for  information  confinement  are 
essential  elements  of  the  overall  system  security  provided 
by  the  SASS. 
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I.  INTRODUCTION 


This  thesis  addresses  the  design  and  partial 
implementation  of  a  memory  manager  for  a  member  of  the 
family  of  secure*  distributed,  multi-microprocessor 
operating  systems  designed  by  Richardson  and  O'Connell  [l] . 
The  memory  manager  is  responsible  for  the  secure  management 
of  the  main  memory  and  secondary  storage.  The  memory  manager 
design  was  approached  and  conducted  with  distributed 
processing,  multi-processing,  configuration  independence, 
ease  of  change,  and  internal  computer  security  as  primary 
goals.  The  problems  faced  in  the  design  were: 

1)  Developing  a  process  which  would  securely  manage 
files  in  a  multi-processor  environment.. 

2)  Ensuring  that  if  secondary  storage  was  inadvertantly 
damaged,  it  could  usually  be  recreated. 

3)  Minimizing  secondary  storage  accesses. 

4)  Proper  parameter  passing  during  interprocess 
communication. 

5)  Developing  a  process  with  a  loop-free  structure 
which  is  configuration  independent. 

5)  Designing  databases  which  optimize  the  memory 
management  functions. 

The  proper  design  and  implementation  of  a  memory 
management  process  is  vital  because  it  serves  as  the 
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interface  between  the  physical  storage  of  files  in  a  storage 
system  anti  the  logical  hierarchical  file  structure  as  viewed 
by  the  user  (viz.,  the  file  system  supervisor  design  by 
Parks  [2]'.  If  the  memory  manager  process  does  not  function 
properly,  the  security  of  that  system  cannot  be  guaranteed. 

The  secure  family  of  operating  systems  designed  by 
Richardson  and  O'Connell  is  composed  of  two  primary  mcduJes, 
the  supervisor  and  the  security  kernel.  A  subset  of  that 
system  was  utilized  in  the  design  of  the  Secure  Archival 
Storage  System  (SASS).  The  design  of  the  SASS  supervisor  was 
addressed  by  Parks  [2] ,  while  the  security  kernel  was 
addressed  concurrently  by  Coleman  f 3] .  The  SASS  security 
kernel  design  is  composed  of  two  parts,  the  distributed 


kernel  and  the  non 

-distributed  kernel 

.  The  design  of 

the 

distributed  kernel  was 

conducted 

by  Coleman  [3]  , 

and 

processor  management  was 

implemented 

by  Reitz  [4]  . 

This 

thesis  presents 

the  design  and 

implementation  of 

the 

non-distributed 

kernel . 

In  the 

SASS  design. 

the 

non-distributed 

kernel 

consists 

solely  of  the  memory 

manager. 

The  design  of 

the  memory  manager 

and  its  data  bases 

was 

completed.  The  initial  code  was  written  in  FLZ/STS,  but 
could  not  be  compiled  due  to  the  lack  of  a  PIZ/SYS  compiler. 

i 

A  thread  of  the  high  level  code  was  selected,  hand  compiled 
into  PIZ/ASM,  and  run  on  the  Z30Z2  developmental  module. 
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The  PIM/ASN*  thread  listing  is  presented  as  a  computer 
program  appended  to  this  thesis. 

A.  BACKGROUND 

Operating  systems  vere  initally  developed  during  an  era 
when  hardware  was  a  scarce  and  expensive  resource,  while 
s,ftware  was  relatively  inexpensive.  The  initial  system 
design  technique  was  to  begin  with  the  hardware 
configuration  and  to  build  the  operating  system  upcr.  it.  The 
"bottom  up"  design  technique  was  practical,  but  it  made  the 
operating  system  extremely  hardware  dependent.  Hardware 
configuration  changes  would  often  force  a  major  software 
redesign,  but  as  lor.g  as  hardware  costs  were  dominant, 
software  modification  was  the  logical  alternative.  As  the 
functions  required  of  the  operating  system  increased,  r.ew 
procedures  were  haphazardly  added  to  the  operating  system, 
often  introducing  new  problems.  Mai ntenerce  and  debugging  of 
the  operating  system  became  extremely  cumbersome  and  time 
consuming. 

The  increased  usage  of  computers  in  such  fields  as 
finance  and  sensitive  information  handling  uncovered  a 
serious  problem  with  most  operating  systems.  Information 
stored  within  a  computer  system  was  generally  quite 
accessible  to  anyone  who  had  a  working  knowledge  of 
operating  system  design  and  structure,  regardless  of  ary 
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ad-hoc  atterpts  to  provide  internal  computer  security.  Data 
stored  in  information  systems,  with  security  added  in,  could 
not  he  certified  as  being  totally  secure[14]». 

Recent  technological  developments  have  reversed  the 
economics  of  the  computer  design  environment. 
Microprocessors  have  become  abundant,  powerful,  and 
inexpensive.  The  relative  cost  of  software,  on  the 
otherhand,  has  steadily  increased  until  it  now  dominates  the 
overall  cost  of  a  computer  system.  This  reversal  has  two 
basic  implications.  First,  software  must  be  treated  as  the 
expensive  commodity.  Software  developed  should  therefore  be 
logical,  easy  to  read,  relatively  maintenance  free,  and  easy 
to  debug.  Second,  more  powerful  hardware  can  be  used  to 
perform  functions  previously  performed  with  software,  and 
thus  hardware  (multiprocessors)  can  be  utilised  to  achieve 
overall  system  speed  goals. 

The  S A.S S  was  developed  utilising  a  "top  down"  design 
technique,  with  information  security  as  a  primary  design 
issue.  Security  was  designed  into  the  system  based  upon  the 
security  kernel  concept  [5],  The  security  kernel  provides  a 
secure  environment  by  ensuring  that  just  one  element  of  the 
system  (the  security  kernel)  is  sufficient  to  provide  the 
internal  system  security.  All  accesses  of  data  stored  within 
the  computer  system  must  be  validated  by  the  security 
kernel . 
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B.  BASIC  CONCEPTS /DEFINITIONS 
1 .  Process 

Organick  [6]  defines  a  process  as  a  set  of  related 
procedures  and  data  undergoing  execution  and  manipulation, 
respectively,  by  one  of  possibly  several  processors  of  a 
computer.  The  process  is  a  logical  rather  than  a  physical 
entity,  and  can  be  viewed  as  a  set  of  related  procedures  and 
data  (referred  to  as  the  process'  address  space)  and  a  point 
of  execution  within  that  address  space.  Each  process  may 
have  associated  with  it  such  logical  attributes  as  a 
security  class  authorization  and  a  unique  identifier.  In 
order  to  execute,  the  process  must  be  mapped  onto  (bound  to) 
a  physical  processor  within  the  computer  system. 

A  process  may  exist  in  one  of  three  states:  blocked, 
ready,  or  running.  When  in  a  blocked  state,  the  process  must 
wait  for  the  occurrence  of  some  event  before  execution  can 
continue  (for  example,  an  access  of  secondary  storage^.  When 
the  ev°nt  for  which  a  blocked  process  is  waiting  occurs,  the 
process  is  placed  into  the  ready  state  which  indicates  that 
the  process  can  run  when  a  processor  is  available  to  be 
assigned  to  it.  The  process  is  in  thp  running  state  when  it 
is  executing  on  a  processor. 


14 


2.  Process  Switching 


When  a  process  is  blocked,  the  physical  processor 
upon  which  it  is  scheduled  is  idle.  For  efficiency  reasons, 
it  makes  sense  to  freeze  that  process,  save  the  execution 
point  (program  status  registers,  program  counter,  execution 
stack)  ar.d  the  address  space,  and  then  schedule  another 
process  to  run  on  that  processor.  This  is  referred  to  as 
process  switching  (or  multiprogramming),  and  is  an  important 
aspect  of  a  distributed  operating  syster.  The  overall 
system,  such  as  SASS,  can  he  viewed  as  a  set  of  cooperating 
processes  that  interact  to  perform  the  intended  functions. 

Efficient  process  switching  can  only  he  achieved 
with  the  support  of  some  hardware  switching  mechanism  that 
will  unload  the  blocked  process'  address  space,  and  load  the 
address  space  of  the  scheduled  process.  Some  systems  have  a 
EFR  (descriptor  base  register)  which  is  used  to  point  to  a 
list  of  multiple  address  spaces  (one  per  process)  which 
exists  in  memory.  Thus  to  change  an  address  space,  the  EFR 
need  only  be  changed.  The  SASS  utilizes  a  Z-8 080  supportirg 
hardware  device  entitled  a  Memory  Management  Unit  (MMU)  to 
allow  efficient  process  switching.  The  MM'J  consists  of  a  set 
of  registers  (64  or  12S  in  the  SASS  design)  which  contain 
the  process'  address  space.  Thus  process  switchirg  would 
involve  the  switching  of  control  to  another  hardware  MMU  (if 
a  hardware  MM'J  were  available  for  each  process),  or 


15 


alternately  loading  a  software  MMU  image  (which  is  always 
kept  current)  into  the  MM'J  whenever  a  process  switch  is 
required.  The  SASS  currently  maintains  a  software  MPU  image 
for  each  process. 
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3.  Protection  Domains 

A  user's  process  executing  on  a  computer  system  has 
an  address  space  which  includes  the  user  provided  procedures 
and  data,  and  also  those  portions  of  the  distributed 
operating  system  which  are  required  to  support  execution  of 
his  program.  To  maintain  system  integrity  and  security,  it 
becomes  mandatory  to  protect  the  operating  system  from  being 
altered  or  manipulated  by  the  user's  procedures.  To  achieve 
this,  the  process'  address  space  is  divided  into  a  set  of 
hierarchical  domains  which  ensure  that  the  segments  of  the 
operating  system  are  protected  from  the  user.  Since  the  top 
down  design  cf  the  operating  system  provides  a  strict 
hierarchal  structure,  the  domains  of  the  operating  system 
are  also  hierarchical  in  structure  (viz.,  are  protection 
rings).  In  the  design  cf  the  secure  operating  system  family, 
three  domains  were  defined:  the  user,  the  supervisor,  and 
the  kernel. 

Operating  system  segments  which  manage  the  actual 
shared  physical  resources  reside  in  the  kernel.  The  kernel 
is  the  most  privileged  domain  of  the  address  space.  It  can 
be  envisioned  as  a  mini-operating  system  that  does  all  the 
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resource  management.  The  security  kernel  segments 
(executable)  can  only  be  accessed  within  the  kernel.  Global 
(system  wide)  data  bases  are  restricted  to  access  by  only 
the  security  kernel  to  prevent  the  possibility  of  an 
unauthorized  inter-prccess  leakage  of  information  [7] . 

The  supervisor  domain  resides  between  the  most 
privileged  kernel  domain  and  the  least  privileged  user 
domain.  The  supervisor  contains  those  segments  of'  the 
operating  system  which  are  required  to  provide  such  common 
services  as  creating  a  hierarchical  file  system.  The 
supervisor  deals  with  the  logical  entities  (segments)  as 
viewed  by  the  user,  and  manages  these  segments  by  calls  to 
the  kernel.  To  preserve  the  integrity  of  the  file  system, 
the  user  is  placed  in  the  least  privileged  domain,  and  can 
communicate  directly  with  the  supervisor  only. 

Multiple  protection  domains  may  be  implemented  via 
either  a  hardware  and/or  a  software  ring  structure.  A 
hardware  implementation  is  more  efficient,  however  the  '''LSI 
microprocessors  currently  being  manufactured  provide  for 
only  two  protection  domains.  The  present  design  of  thp  SASS 
requires  two  domains,  separating  the  supervisor  and  the 
security  kernel.  The  Z£0(?-0  microprocessor  provides  the  SASS 
with  the  hardware  ring  structure  ty  providing  two  execution 
modes,  the  system  mode  and  the  normal  mode.  The  kernel 
executes  in  the  system  mode  and  thus  has  access  to  all 
segments,  machine  instructions,  ar.d  hardware  facilities.  The 


supervisor  executes  in  the  normal  mode,  and  thus  only  has 
access  to  a  subset  of  the  instruction  set  and  segments.  The 
supervisor  does  not  have  access  to  those  instructions  which 
manipulate  the  system  hardware,  such  as  special  I/O  and 
execution  mode  control  instructions. 

4.  Segmentation 

Segmentation  is  the  key  element  of  a  secure  system. 
A  segment  is  a  logical  grouping  of  information  such  as  a 
procedure,  array,  or  data  area  [6],  The  address  space  of  a 
process  consists  of  those  segments  that  may  he  addressed  by 
that  process.  Segmentation  is  the  management  of  those 
segments  within  the  address  space.  In  order  to  address  a 
specific  location  within  a  segment  two  dimensions  are 
required,  an  identification  of  the  segment  (e.g..  segment 
number)  and  an  offset  from  the  base  of  the  segment. 

Sach  segment  may  have  several  logical  attributes 
associated  with  it.  These  attributes  can  include  segment 
size,  classification,  and  access  permitted  (r  .ad,  write, 
execute).  The  physical  attributes  of  a  segment  include  the 
current  base  address,  and  whether  or  not  the  segment  is  "in 
core".  The  segment's  attributes  and  its  physical  location  in 
memory  are  contained  in  a  segment  descriptor.  The  segment 
descriptors  for  a  process  are  often  contained  in  a 
descriptor  list  (viz.,  an  PMC  image  for  the  SA.SS)  to 
facilitate  the  memory  management  of  its  address  space. 
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Segmentation  permits  multiple  processes  to  share  a 
single  segment  and  to  avoid  the  requirement  of  maintaining 
duplicate  copies  in  memory.  This  eliminates  the  possibility 

t 

of  having  conflicting  data  when  multiple  copies  of  the  same 
segment  are  maintained.  Segmentation  also  enables  the 
enforcement  of  controlled  access  to  a  particular  segment, 
since  each  process  car.  have  different  access  (read/write)  to 
stored  segments.  This  capability  of  enforcing  controlled 
access  is  crucial  to  security. 

Segmentation  provides  a  mechanism  for  the 
virtualization  of  memory  (although  not  provided  in  the 
SASS).  If  a  user  requests  access  to  a  segment  to  which  he 
has  access  rights,  and  that  segment  is  not  in  main  memory,  a 
memory  fault  will  occur  which  will  cause  that  segment  to  be 
loaded  into  main  memory  (another  segment  may  have  to  be 
moved  to  secondary  storage  to  make  room).  Thus  to  the  user, 
the  size  of  main  memory  is  virtualized  into  the  size  of  the 
process'  address  space. 

5.  Information  Security 

As  previously  stated,  there  is  an  ever  increasing 
demand  for  a  computer  system  to  provide  for  the  secure 
storage  of  information.  This  security  cannot  be  added  to  an 
existing  operating  system  with  a  large  degree  of  confidence 
that  the  resulting  security  system  cannot  be  avoided  or 
bypassed.  In  order  to  be  demonstrably  adequate,  security 
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trust  "be  designed  into  the  operating  system,  and  must  he  part 
of  the  cornerstone  upon  which  the  operating  system  is  built. 

There  are  two  basic  aspects  of  information  security, 
external  security  and  internal  security.  External  security 

i 

prevents  an  infiltrator  from  getting  to  the  object  in  which 
the  desired  information  is  stored.  This  can  be  of  such  form 
as  a  fence,  a  safe,  a  sentry,  or  a  guard  dog.  If  an 
infiltrator  manages  to  penetrate  these  external  security 
measures,  he  then  has  access  to  the  desired  information. 
Internal  controls  would  consist  of  those  security  measures 
internal  to  the  computer  which  impede  and  if  effective, 
prevent  a  compromise  of  information.  If  the  internal 
controls  function  properly,  information  is  provided  and 
exchanged  only  with  the  users  wnc  are  explicitly  authorized 
access  to  that  information.  Many  information  systems  are 
required  tc  store  and  access  information  of  different 
security  levels  (e.g.,  secret  files  interspersed  with 
confidential  and  unclassified).  The  internal  security  of 
such  a  "multilevel"  system  must  permit  users  and  information 
to  exist  simultaneously  at  different  security  levels,  ar.d 
also  ensure  that  no  unauthorized  accesses  (either 
intentional  or  unintentional)  are  permitted.  The  SASS  was 
designed  to  provide  a  multilevel  secure  storage  environment. 

The  data  to  be  stored  in  a  secure  information  system 
can  be  looked  upon  as  a  set  of  logical  objects  such  as  files 
or  records.  Associated  with  each  of  these  objects  is  a  set 
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of  subjects  which  have  access  rights  to  that  object.  These 
access  rights  may  include  read  access,  write  access,  or  a 
combination  thereof.  The  con-discretionary  security  policy 
involves  checking  the  object's  access  class  (oac)  with  the 
subject's  access  class  (sac)  to  ensure  that  they  are 
compatible.  The  access  permitted  is  defined  in  a  lattice 
model  of  secure  information  flow  [9]  as  follows: 

sac  *  oac,  read  and  write  access  permitted 
sac  >  oac,  read  access  permitted 
sac  <  oac,  no  access  permitted 
The  government  security  classification  system 
provides  an  example  of  a  non-discretionary  security  policy. 
A  user  with  a  security  clearance  of  confidential  is 
authorized  read  and  write  access  to  a  confidential  file  (sac 
=  oac),  and  he  has  read  access  (but  not  write)  to  an 
unclassified  file  (sac  >  oac).  This  restriction  on  write 
access  is  to  prevent  the  inadvertant  writing  of  confidential 
data  into  an  unclassified  file  to  which  the  subject  may  have 
simultaneous  access  (this  property  is  often  referred  to  as 
the  ^-property  [10]).  Finally,  the  confidential  subject  dees 
not  have  access  to  any  secret  files  (sac  <  oac). 

Th°  discretionary  security  policy  involves  checking 
the  subject  against  an  object's  access  control  list  (ACL'. 
The  subject  only  has  access  to  an  object  if  he  is  included 
in  its  AC1 .  This  policy  is  analagous  with  the  government's 
“need  to  know"  policy,  wnicn  precludes  a  subject  with  a 


secret  clearance  from  having  access  rights  to  all  secret 
information  within  the  system.  He  may  access  only  that  for 
which  he  has  a  "need  to  know".  The  discretionary  security 
policy  thus  allows  the  users  of  the  system  to  specify  who 


has  access  to 

their  files.  It  is 

noted  that 

the 

discretionary 

security  policy  is  a 

refinement 

of 

the 

security  policy 

,  and  never  permits  a 

violation 

of 

the 

non-discretiona ry  security  policy  in  effect. 

The  SASS  was  designed  with  the  internal 
non-discretionary  security  to  be  provided  by  the  security 
kernel.  Discretionary  security  is  provided  by  the  supervisor 
file  system.  The  security  kernel  is  based  upon  a 
mathematical  model  which  has  teen  proven  correct.  This 
mathematical  model  implements  the  system's  security 
policies . 

The  security  kernel  design  has  thre*  prerequisites 
in  order  to  provide  a  secure  environment:  1'  the  kernel  must 
ye  isolated  to  ensure  that  it  cannot  be  modified  either 
intentionally  or  inadvertantly.  This  is  to  ensure  that  the 
behavior  of  the  kernel  cannot  be  modified.  2)  Each  and  every 
attempt  to  access  data  within  the  system  must  invoke  the 
kernel.  3)  The  kernel's  correctness  must  be  :fiatle.  This 
implies  tHat  the  mathematical  model  must  be  proved  and 
demonstrated  as  secure,  and  that  the  kernel  implements  this 
model . 
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C.  THESIS  STRUCTURE 


This  thesis  presents  the  detailed  design  of  a  memory 
management  process  for  the  SASS.  The  top  down  design 
technique  was  utilized,  with  levels  of  abstraction  used  to 
reduce  the  design  complexity.  The  high  level  language 
utilized  was  PLZ/3YS,  which  was  designed  to  be  compatible 
with  the  2B2£l  microprocessor.  PI2/S7S  is  a  block  structured 
language  similar  to  PASCAL.  The  compiler  which  compiles  from 
PI2/STS  tc  the  Z82C1  instruction  code  is  still  in  the 
developmental  stage  at  2ILCG,  INC.  The  PIZ/STS  code  had  to 
therefore  be  "hand  compiled"  (viz. .translated  to  the  PI2/ASM 
assembly  language)  in  order  to  run,  test,  and  debug  the 
code.  Some  of  the  procedures  in  the  lover  levels  of  design 
(those  which  use  privileged  instructions  to  directly 
manipulate  the  system  hardware)  must  be  directly  coded  using 
the  assembly  cod?  FLZ/ASM.  These  procedures  were  declared 
external  to  the  Kemory^anager.FlZ/SYSJ’todule  and  are  coded 
in  the  Memory_Manager_?LZ/ASM_Module . 

Chapter  II  of  the  thesis  presents  an  overview  of  the 
SASS  at  its  current  stage  of  development.  The  design  of  the 
memory  management  process,  and  the  concurrent  implementation 
of  the  distributed  kernel  processor  management  by  Reitz  [4] 
refined  the  original  design  of  Parks  and  Coleman.  Future 
vcrk  in  the  SASS  will  most  likely  require  some  refinemert  of 
♦he  present  design. 
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Chapter  III  presents  the  detailed  design  of  the  memory 
manager  module.  This  chapter  emphasizes  why  certain  desien 
features  were  chosen,  and  how  they  were  implemented  in  this 
design. 

The  final  chapter  presents  the  status  of  research  to 
date,  and  attempts  to  identify  what  follow-on  work  is 
required.  The  PL2/SYS  code  module  and  the  PIZ/AS^  code 
module  are  presented  as  appendices. 


II.  S?C?TS2  A5CHIYAI  STORAGE  SYSTEM  rSSIGM 


This  chapter  presents  an  overview  of  the  S A SS  in  its 
current  state  of  development.  It  is  a  summation  of  the 
original  design  efforts,  and  reflects  refinements  of  those 
original  designs.  This  overview  is  necessary  in  order  to 
fully  understand  the  interrelationship  between  the  memory 
manager  and  the  overall  system  design.  It  also  provides  a 
current  base  for  further  SASS  development. 

A.  BACIC  CvmiTd 

The  purpose  cf  the  SASS  is  to  provide  a  secure  archival 
file  storage  medium  for  a  variable  number  of  host  computers. 
The  kev  design  .seals  of  the  SASc  Were  multi-level  internal 
computer  security  and  ''or.trolleu  sharing  cf  data  amone 
authorized  users. 

Figure  1  provides  an  example  of  hew  the  SASS  could  be 
used.  In  this  example,  there  are  four  host  computers  which 
reside  in  four  separate  rooms  (consider  each  of  these 
computers  to  be  microcomputers,  although  any  computer  could 
b<:  utilized).  Fach  of  the  four  hosts  are  used  to  create  and 
manipulate  files  of  fixed  predetermined  security 
classification.  For  example,  all  files  created  by  host  *2 
are  classified  secret.  Host  £2  cannot  create  top  secret. 


TOP  SECRET 


SECRET 


CONFIDENTIAL 


UNCIASSIFIED/ 

CONFIDENTIAL 


Figure  1.  SASS  System 
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confidential,  or  unclassified  files  (nor  can  he  access  top 
secret,  in  this  example).  Access  to  each  of  these  rooms  is 
physically  controlled  to  ensure  that  only  personnel  with  the 
proper  security  clearance  are  authorized  access.  None  of  tr.s 
host  systems  have  a  permanent  local  file  storage  device,  and 
all  are  hard-wired  to  an  I/O  port  of  the  SASS. 

3ach  host  controls  the  access  to  its  I/O  ports  (host  *4 
illustrates  the  multi-level  host  connection  currently 
required  hy  the  SASS).  The  physical  protection  of  the 
hard-wire  is  assummed  to  be  adequate  to  minimize  tr.e 
possibility  of  such  malicious  activities  as  wire  tapping  or 
emanations  monitoring.  Once  a  user  of  the  host  system 
completes  his  work,  he  can  permanently  store  his  file  on  the 
SASS ,  which  is  contained  in  the  fifth  room  of  figure  1  ('dew 
the  SASS  as  an  ZSCCi  microcomputer  with  access  to  secondary 
storage  devices).  To  gain  access  to  c  file,  the  user  or  0/? 
of  the  host  system  must  request  the  SASS  to  provide  him  wit'' 
that  file.  This  implies  that  if  a  malicious  user  gains 
access  of  the  confidential  cost  system,  he  still  cannot 
access  files  of  a  higher  classification. 

The  SASS  must  te  capable  of  performing  three  basic 
functions  in  this  environment.  These  functions  are:  store 
a  file  for  a  host  system,  2)  retrieve  a  file  for  a  host 
system,  and  3)  ensure  that  the  the  files  are  made  available 
only  to  authorized  users.  The  required  capabilitv  of  file 
storage  and  retrieval  implies  that  processes  must  exist  for 
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each  host  system  to  perform  file  management  and  data 
transfer  or.  behalf  of  that  host.  To  ensure  the  security  of 
the  stored  information,  the  SAS5  must  ensure  that  the  user 
of  a  specific  host  system  may  only  address  the  files  to 
which  he  has  access.  The  S  AS  S  achieves  the  desired 
environment  through  a  distributed  operating  system  design 
which  consists  of  two  primary  modules,  the  supervisor  and 
the  security  kernel  (the  security  kernel  actually  consists 
of  distributed  and  non-di btributed  portions).  Tach  host 
system,  which  is  hardwired  to  the  SASS,  communicates  with 
its  own  I/O  process  and  file  manager  orocess  in  the  SASS 
itself. 

The  supervisor  is  responsible  for  the  SASS-hcst  system 
interface.  It  constructs  and  manages  a  hierarchical  file 
system  for  its  host,  based  upon  th«  files  which  the  host  has 
submitted,  and  controls  the  actual  I/O  (both  data  and 
commands)  between  the  SASS  and  the  host  system.  ThP 
supervisor  is  built  upon  the  security  kernel  and  performs 
the  host's  requests  (file  storage,  file  retrieval,  I/O)  bv 
calls  to  the  security  kernel.  These  calls  must  be  validated 
(by  a  gate  keeper  module  in  the  SASS  design)  before  the 
security  kernel  function  is  invoked. 

The  SASS  security  kernel  consists  of  a  distributed  and 
non-distributed  kernel.  The  distributed  kernel  is 
distributed  to  (viz.,  is  in  the  address  space  of^  every 
process,  and  is  responsible  for  the  multiplexing  of  the 
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several  processes  onto  the  actual  hardware  processors ' , 
enforcing  the  non-discretionary  security  policy.  and 
providing  the  synchronization  primitives  for  inter-uro^ess 
communication.  The  non-dist ributed  kernel  consists  of  the 
memory  manager  process  which  is  responsible  for  the  secure 
management  of  both  main  memory  and  secondary  storage.  Each 
hardware  processor  must  have  its  own  memory  manager  (ergo, 
non-di stributed  kernel)  in  the  SASS  design. 

An  abstract  system  overview  of  the  SASS  is  presented  in 
figure  2.  Four  levels  of  abstraction  were  utilized  to 
simplify  the  design  and  understandability  of  the  system. 

Level  ?  consists  of  the  system  hardware  which  includes 
the  7.8PP1  microprocessor,  the  local  and  global  memories,  and 
secondary  storage.  The  ^ ASS  is  designed  to  ocerate  ir.  a 
multi-microprocessor  environment,  therefore  each  CPU  is 
assigned  its  own  local  memory  (to  which  it  alone  has  access' 
ir.  which  it  car.  store  process  local  segments.  The  system 
contains  a  global  memory,  which  every  CPU  may  access. 
Segments  to  which  a  user  process  has  write  access  must  be 
:'~red  in  global  memory  if  more  than  one  process  has 
simultaneous  access  to  that  segment.  This  is  to  ensure  that 
all  processes  access  the  current  copy  of  that  shared 
writable  segment.  The  basic  storage  policy  is  to  store  every 
segment  within  local  memory  if  at  all  possible.  This  is  to 
keep  bus  contention  between  processors,  which  access  global 
memory,  to  a  minimum. 
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Figure  2.  SASS  Abstract  System  Overvi 
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Level  1  consists  of  the  distributed  and  non-di stn bated 
kernel.  The  kernel  is  placed  in  (executes  in)  the  rrost 
privileged  domain  (system  mode)  of  the  Z6ZC1  to  ensure  that 
it  is  protected  from  any  manipulation  (either  malicious  or 
inadvertanO .  The  kernel  controls  all  access  to  the  system 
hardware  by  maintaining  all  privileged  machine  instructions 
within  its  domain.  Only  the  kernel  may  access  these 
instructions.  The  distributed  kernel  is  responsible  for 

creatine  a  virtual  processor  environment  and  enforcing  the 

\ 

non-discretionary  security  policy.  It  multiplexes  processes 
onto  virtual  processors  and  then  multiplexes  these  virtual 
processor(s)  onto  the  actual  hardware  processors.  The 
non-distributed  kernel  consists  of  the  memory  manager  and  is 
responsible  for  the  secure  management  of  both  main  memory 
and  secondary  storage. 

level  2  consists  of  the  supervisor,  which  resides  in  the 


less  privileged 

doma 

in  (normal 

mode ) 

of  the  Z?m 

microprocessor. 

It 

has  access 

to 

all  the  machine 

instructions  with 

the 

exception  of 

those 

which  manipulate 

the  system  hardware.  The  supervisor  must  request  the  kernel 
to  move  segments  into  and  out  of  memory  and  secondary 
storage  via  the  gate  keeper  >'a  software  assisted 
ring-crossing  mechanise ).  The  supervisor  consists  of  two 
surrogate  processes  for  each  host,  the  I/O  (input/output' 
orocess  and  the  (file  management)  process.  By  utilizing 
the  I/O  and  processes  the  supervisor  is  able  to  nrovide 
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and  manage  a  virtual  file  hierarchy  for  each  host  system. 
Fach  host  system  has  I/O  and  FM  processes  created  and 
assigned  at  system  generation.  They  are  not  dynamically 
created  or  deleted.  The  supervisor  ensures  that  each 
segment's  discretionary  security  is  enforced. 

Level  3  consists  of  the  host  computer  systems.  These 
systems  are  hardwired  to  the  I/O  ports  of  the  ZB222 .  The 
hosts  communicate  with  the  SASS  via  system  protocols  over  a 
communication  link.  Any  computer  system  could  serve  as  a 
host,  with  each  host  supporting  multiple  users. 

3.  SUPERVISOR 

Sach  host  system  is  assigned  the  dedicated  services,  of  a 
pair  of  supervisor  processes  at  system  generation.  These 
nrocesses  are  the  I/C  and  I'd  processes.  The  FM  process  and 
the  I/O  process  communicate  with  each  other  via  a  shared 
segment  entitled  the  "mailbox".  This  communication  is 
synchronized  via  the  kernel  synchronization  primitives  which 
act  upon  eventcounts  and  sequencers  [12]  .  A  virtual  file 
system  is  created  and  maintained  for  each  host  by  its  FM  ar.d 
I/O  processes. 

1 .  File  Management  Process 

The  FM  process  is  responsible  for  the  management  of 
the  host'1-  virtual  file  system  wit.niu  the  SASS.  The  Fw. 
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process  interprets  all  the  host  commands  and  acts  upon  them 
in  conjunction  with  the  I/O  process. 

The  user  of  the  host  system  views  his  stored  data 
(within  the  SASS)  as  a  hierarchy  of  files.  Figure  3  provides 
an  example  of  such  a  hierarchical  file  structure.  To  specify 
a  particular  file,  a  pathname  is  required.  The  pathname  is 
simply  a  concatenation  of  the  file  names  (given  to  each  file 
"by  the  user  at  its  creation)  starting  at  the  ”roct" 
directory  and  proceding  sequentially  to  the  desired  file. 
The  user  is  required  to  submit  a  pathname  with  each  command 
sent  to  the  SASS.  The  five  basic  actions  to  be  performed 
upon  files  at  this  level  are:  1)  to  create  a  file  (data  or 
directory!,  2!  to  delete  a  file,  3!  to  read  a  file  (data  or 
directory),  4)  to  initiate  or  modify  file  attributes  (si2e, 
classification,  access  permitted!,  and  5)  to  store  (write!  a 
file. 

The  FM  process  is  required  to  convert  the  pathname 
provided  by  the  user,  into  one  or  more  segment  numbers.  This 
is  necessary  because  the  notion  of  a  file  is  not  known 
within  the  kernel,  ill  files  are  composed  of  segments,  and 
rust  be  referenced  as  segments  within  the  kernel  for 
manipulation  and  management.  The  FM  process  must  also 
provide  appropriate  command  handlers  to  ensure  that  the 
user's  requested  actJon  is  properly  carried  out. 

The  SASS  permits  a  host  tc  read  or  write  the  files 
of  another  host,  at  the  same  security  level,  if 
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discretionary  access  is  permitted.  Files  of  a  lower 
classification  may  be  read  only  (if  discretionary  access  is 
permitted).  This  file  sharing  is  achieved  by  creating  a  link 
between  the  two  file  hierarchies.  This  link  is  entered  into 
a  directory  file  of  the  host,  and  is  constructed  in  the  same 
manner  as  a  pathname  (viz.,  it  is  a  concatenation  of 
filenames).  The  kernel  enforces  a  read  only  access  to  the 
lower  classified  files,  which  prevents  the  possibility  of 
writing  data  (through  a  link)  of  a  higher  classification 
into  a  file  of  lower  classification. 

The  database  utilized  by  the  FM  process  to  manage 
the  host's  files  is  the  I'd  Known  Segment  Table  (FM_KST'.  The 
FVJTST  is  a  list  of  those  segments  which  are  known  to  (viz., 
within  the  address  space  of)  the  FM  process.  Figure  4 
provides  an  example  of  the  FPJCST  structure. 

Whenever  a  user  of  a  host  syster  requests  access  to 
a  specific  file,  the  FMJCST  is  searched  to  determine  if  that 
pathname  (segment)  is  already  known.  If  it  is  known,  the 
request  is  passed  to  the  kernel,  via  the  gate_keeper,  with 
the  appropriate  ..  _«t  number,  for  the  desired  action.  If 
the  pathname  is  not  known,  the  segment  number  of  the  desired 
file's  directory  (parent)  file  and  an  entry  number  are  sent 
to  the  kernel  with  the  request  to  make  that  segment  known. 
If  the  request  is  authorized  by  the  kernel,  a  segment  number 
and  access  mode  authorized  are  returned.  The  returned 
segment  number  and  mode  are  then  entered  into  the  Fh_KST 
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Path 

Name 

Seg_* 

Access 

Mode 

Use 

Host_l>Adams>File_C 

50 

R 

N 

Host  J2>Green>Dir_l 

44 

V 

Y 

Host  l>Smith>File_l 

22 

V 

N 

Host_l>Smith>Iink-1 

44 

R 

Y 

Figure  4.  File  Manager  Known  Segment  Table. 
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with  that  segment's  pathname.  Once  the  segment  is  known,  the 
desired  user  action  can  he  carried  out. 


The  user  requests  to  create  or  delete  files  are 
simply  passed  to  the  appropriate  kernel  procedure,  via  the 
gate  keeper,  hy  the  Ftf  process  (after  a  discretionary 
security  check).  No  entries  are  added  or  deleted  from  the 
FMJCST  during  create  or  delete  requests  (they  invoke  kernel 
primitives  which  add  or  delete  entries  from  a  kernel  data 
base) . 

Should  the  ?M  process  request  that  a  segment  he 
swapped  into  memory  and  memory  is  full,  an  error  code  will 
he  returned  to  the  FM  process  from  the  kernel  (it  is  noted 
that  this  is  a  per  process  memory  allocation,  thus  the 
nemcry  state  cannot  he  affected  hy  its  use  by  other 
processes).  The  FM  process  will  then  select  a  segment  to  he 
removed  from  core  to  make  room  for  the  desired  segment.  The 
current  design  calls  for  the  invocation  of  a  least  recently 
used  algorithm  (IR’J)  which  makes  use  of  the  Fvi_KST  "used" 
field  to  determine  the  least  recently  used  segment  for  swap 
out . 

Fiscret ionary  security  is  enforced  in  the 
di scretior.ay  security  module  of  the  FM  process.  An  access 
control  list  (ACl^  is  maintained  for  each  file  within  the 
file  hierarchy.  The  ACL  is  simply  a  list  of  authorized  users 
(a  refinement  of  non-discretionary  security'  which  is 
checked  for  each  access  to  that  file.  The  discretionary 
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security  module  also  performs  the  housekeeping  functions  for 
the  file's  ACL.  These  functions  include  the  addition  of  a 
ACL  entry,  the  deletion  of  an  AC1  entry,  and  the 
initialization  of  an  ACL  for  a  new  file. 

It  is  noted  that  the  original  design  of  the  FM 
process  contained  a  memory  manager  procedure.  This  was 
necessary  because  the  original  SASS  design  called  for  the 
partitioning  of  memory  such  that  each  supervisor  maintained 
his  own  core.  The  FM  memory  manager  managed  this  virtual 
core  by  calls  to  the  kernel  via  the  gate  keeper  (swap_ir. ♦ 
swap_out).  The  current  design  of  the  non-distributed  kernel 
includes  memory  allocation  and  thus  has  removed  the  need  for 
the  supervisor  to  manage  its  own  virtual  core.  Fecause  of 
this,  a  7K  menorv  manager  is  not  required. 

2.  Input/Output  Process 

The  I/C  process  is  responsible  for  all  the  input  and 
output  between  th°  supervisor  and  the  nost  computer  system. 
The  I/O  process  receives  its  commands  from  the  FM  process 
via  the  shared  mailbox  segment. 

Bata  is  transfered  between  the  host  systems  and  the 
SASS  in  fixed  size  ’’packets”.  There  are  three  basic  types  of 
packets,  a  synchronization  packet,  a  command  packet,  and  a 
data  packet.  Protocols  exist  for  the  reliable  transmission 
and  receipt  of  the  packets  by  both  the  SASS  and  the  host 
systems.  The  current  design  calls  for  the  use  of 
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multi-packet  protocols,  which  allows  the  sender  to  send 
several  packets  before  he  receives  a  receipt. 

The  original  design  of  the  I/O  process  contained  a 
Memory  Manager  procedure  for  the  same  reasons  as  the  ?M 
process.  This  procedure  is  no  longer  required  due  to  the 
design  of  the  non-distributed  kernel. 

C.  BISTRIFUTSD  FERNS! 

The  initial  design  of  the  security  kernel  as  presented 
by  Coleman  [3],  has  been  developed  by  Reitz  [4]  and  the  work 
presented  here.  The  primary  refinements  have  teen  the 
replacement  of  block/wakeup  [3]  by  eventcoun t$ ,  the 
inclusion  of  an  event  manager  which  contains  the 
synchronization  primitives,  and  the  transfer  of  tn 
management  to  the  memory  manager.  Figure  5  provides  an 
overvipw  of  the  security  kernel  design. 

1 ,  C-aie  Keeper 

Th°  gate  keeper  is  a  software  ring  crossing 
mechanism  which  is  utilized  to  ensure  that  the  security 
kernel  is  isolated  and  tamperproof.  The  major  issues  of  the 
gatekeeper  design  arp:  1}  to  provide  a  rode  switching 
mechanism  for  switching  from  normal  (supervisor)  mode  to 
system  (kernel)  mode  2)  tc  mask  hardware  preempt 
interrupts  in  the  kernel,  and  2)  to  check  for  "virtual" 
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software  oreemot  interrupts  when  leaving  the  kernel.  The 
sate  keeper  provides  the  sole  entry  point  into  the  kernel 
domain,  validates  the  request  and  its  arguments,  and 
transfers  the  request  to  the  appropriate  kernel  procedure. 
If  the  sate  keeper  encounters  an  error,  it  returns  an 
appropriate  error  code  without  irvoking  the  kernel. 

The  sate  keeper  uses  a  parameter  table  to  validate 
the  user's  request  (call  by  value  only).  This  table  contains 
the  number  of  parameters  required  by  each  kernel  function 
( create_segmer.t  ,delete_segment ,  etc.),  the  type  of  each 
parameter,  and  the  type  of  each  return  parameter.  If  an 
error  is  discovered  during  the  validation  process,  it  sets 
the  return  message  to  an  error  code.  If  the  request  is 
valid,  the  gate  keeper  calls  the  appropriate  kernel  module. 

The  gate  keeper  is  a  trap  handler.  The  supervisor 
puts  an  argument  list  ar.d  space  for  a  return  message  in  a 
segment  (or  processor  registers'  within  the  supervisor's 
domain.  When  the  fate  keeper  is  invoked,  it  must  first  save 
the  supervisor  processor  registers  and  then  retrieve  the 
argument  li«t  (via  an  argument  list  pointer  repister'.  The 
arguments  are  validated  and  if  correct,  passed  to  the 
appropriate  kernel  module. 

'•.’her  the  kernel  completes  action  taken  upon  the  user 
request,  it  returns  to  the  gate  keeper.  The  gate  keeper  then 
copies  a  return  message  intc  the  return  argument  (that  is 
returned  to  the  supervisor's  domain),  restores  the 
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supervisor's  environment ,  unmasks  the  interrupts,  and  makes 
a  trap  return  hack  to  the  supervisor  (viz.,  changes  the  mode 
hack  to  normal). 

2.  Segment  Manager 

The  segment  manager  is  responsible  for  the 
management  of  t.he  segmented  virtual  memory.  There  are  six 
functions  which  the  segment  manager  is  called  upon  to 
perform.  These  functions  are:  1)  to  create  a  segment,  2)  to 
delete  a  segment,  Z)  to  make  a  segment  known,  O  to  make  a 
segment  unknown  (terminate),  5)  to  swap  a  segment  into  core, 
and  6)  to  swap  a  segment  out  of  core. 

The  segment  manager  uses  the  Known  Segment  Table 
(KST)  as  its  data  base  to  manage  segments.  The  KST  is  a 
process  local  kernel  data  base  which  contains  entries  for 
all  the  segments  which  the  process  has  made  known.  Figure  6 
provides  an  example  of  the  KST  structure.  The  KST  size  is 
fixed  at  system  veneration.  It  is  indexed  by  Segment  numbers 
which  are  assigned  by  the  segment  manager.  When  a  segment  is 
made  known,  a  "handle"  (the  concatenation  of  the  Global 
Active  Segment  Table  (G_AST)  index  and  the  segment's  unique 
identification'  is  returned  to  the  segment  manager  by  the 
memory  manager.  The  handle  is  a  system  wide  unique 
identification  that  is  assigned  to  ea~h  active  segment 
(viz.,  active  in  the  G_ASTi.  The  KST  provides  the  mapping 
mechanism  for  converting  the  segment  number  into  the 
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Segment,.# 


Figure  6.  Known  Segment  Table 


segment 's  unique  handle.  The  use  of  the  unique  handle  by  the 
memory  manage,  is  what  permits  the  controlled  sharing  of 
segments  hy  concurrent  processes.  Any  process  which  requests 
to  make  a  specific  segment  active  will  always  he  returned 
that  segment's  unique  handle.  Thus  any  one  segment  may  exist 
within  the  address  space  of  several  processes  (with  a 
different  segment  number  in  each  process)  while  residing  in 
one  location  in  memory. 

The  SI2T  field  of  the  KST  represents  that  segment's 
size.  Segments  exist  in  multiples  of  256  bytes  due  to 
MMU  hardware  constraints.  An  upper  bound  upon  the  segment 
size  is  fixed  at  system  generation  by  the  design  parameter 
nax_segmprt_size.  This  is  lirited  to  65K  bytcs  by  hardware, 
the  ACC?SS_^or3  field  states  the  access  authorized  to  the 
segment  (r*»ad,  write)  by  this  process.  The  IN’_C0?.T  field  is 
set  when  a  process  successfully  requests  the  segment  to  be 
swapped  irto  core.  The  CLASS  field  is  used  to  give  the 
access  class  (e.g.,  secret,  confidential!  of  the  segment. 

The  usual  sequence  of  invoking  the  segment  manager 
functions  (by  the  supervisor)  would  be  as  fellows:  1' 
Create_Segmer.t  (this  will  invoke  the  memory  manager  to 
assign  a  unique  identification  to  the  created  segment',  2) 
Mak?_Known,  which  will  place  the  segment  irtc  the  KST,  and 
.?)  Swap_In,  which  will  move  the  segment  from  secondary 
storage  to  main  memory.  To  remove  a  segment  from  main  memory 
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to  secondary  storage,  the  order  would  he  1)  Swap_Out,  2) 
va'£e_Unk:novn ,  and  ?)  Eelete^Segment . 

3.  Event  Manager 

The  event  manager  provides  the  kernel 
synchronization  primitives  that  are  used  for  the 
synchronization  of  concurrent  processes  in  the  supervisor  of 
the  present  SASS  design.  The  synchronization  mechanism  used 
is  that  o?  eventcounts  and  sequencers,  first  proposed  by 
Heed  and  Eanodia  [1C].  The  use  of  eventcounts  and  sequencers 
allows  the  ordering  of  events  to  be  controlled  directly  by 
the  processes  involved,  rather  than  to  depend  upon  mutual 
exclusion  mechanisms  such  as  semaphores.  The  actual 
eventcounts  are  maintained  in  the  memory  manager  module  as 
they  are  a  system  vide  entity  and  are  not  process  local. 

Heed  and  Xancdia  define  an  ever.tccunt  as  an  object 
that  keeps  a  count  of  the  number  of  events  in  a  particular 
class  that  have  occurred  sc  far  in  the  execution  of  the 
system.  The  event  observed  can  be  anything  from  the  input  of 
data  to  the  system,  to  writing  a  particular  segment.  The 
eventcount  can  be  viewed  as  an  integer  value,  which  is 
incremented  with  each  occurrence  of  the  observed  event.  The 
primitive  AFVANCWX)  is  used  to  signal  the  occurrence  of  a 
particular  event,  and  causes  the  eventcount  X,  associated 
with  that  event,  to  be  incremented.  The  primitive  HEATO:' 
will  return  the  value  of  the  eventcount  X.  The  primitive 
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A.tfAIT(X  ,n)  will  suspend  the  calling  process  until  the  value 
of  eventcount  X  is  greats’*  then  or  equal  to  the  integer 
value  n. 

A  sequencer  can  he  defined  as  an  abstract  object 
that  can  be  utilized  to  totally  order  the  events  of  a 
particular  class.  The  basic  purpose  of  the  sequencer  is  to 
provide  a  means  to  determine  an  ordering  of  a  set  of 
occurences  of  a  particular  event.  I i ke  the  eventcount,  the 
sequencer  can  be  viewed  as  an  integer  value  which  is 
increm°nted  each  time  the  primitive  TICKST(S)  is  called.  The 
TICKET  primitive  is  based  upon  the  ticket  machines  often 
used  in  barbershops  and  ice  cream  stores.  When  a  customer 


enters , 

he  takes  a  ticket. 

from 

which  the 

order 

of 

arrived 

first  and  whom 
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be  served 

rer  t 

can 

determined . 

The  use  of  eventcovnts  and  sequencers  by  the  SASS 
supervisor  can  be  illustrated  ns  follows.  Suppose  that 
serment  A  is  currently  being  updated  by  process  one, 
Eventcount  A  currently  has  the  value  of  9  (the  eventcount 
associated  with  the  reading  of  segment  A).  Process  two 
desires  to  read  segment  A,  so  he  obtains  a  ticket  by 
utilizing  the  TICKET  primitive  associated  with  segment  A. 
The  value  returned  by  TICKET  is  1C.  process  two  now  calls 
upon  the  primitive,  AWAIT ( A ,  10) ,  which  will  suspend  process 
two  until  eventcount  A  is  valued  at  1C.  /hen  process  one 
completes  his  update,  he  will  execute  ABVANCE(A),  which  will 
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increment  eventcount  A  to  the  value  of  10.  This  will  allow 


the  AWAIT (A. If >  to  return  to  process  two,  which  will  then  te 
allowed  to  read  segment  A. 

4 .  Traffic  Controller 

The  traffic  controller  performs  toe  function  of 
scheduling'  processes  to  run  on  virtual  processors.  The 
traffic  controller  could  te  designed  to  schedule  processes 
to  run  directly  on  the  hardware  processors,  but  in  this 
design,  Reed's  [ill  notion  of  a  two  level  traffic  controller 
was  utilized.  Thus  the  processes  are  first  multiplexed  onto 
virtual  processors  by  the  traffic  controller.  The  virtual 
processors  are  then  multiplexed  onto  the  actual  hardware 
processors  by  the  inner  traffic  controller. 

A  virtual  processor  is  an  abstract  data  structure 
which  preserves  all  the  attributes  of  a  process  in  execution 
on  a  processor  (i.e.,  an  execution  point  and  ar  address 
space).  Multiple  virtual  processors  may  exist  for  a  single 
physical  processor.  The  Active  Process  Table  (APT)  is  the 
data  base  utilized  by  the  traffic  controller  to  ccntol  and 
manage  the  multiplexing  of  processes  onto  virtual 
processors.  Figure  ?  provides  an  example  of  the  the  APT. 

The  APT  is  a  fixed  sized  table  which  contains  an 
ertry  for  each  process  of  the  PASS  (the  processes  are 
created  at  system  generation).  Eecause  of  the  design 
decision  rot  to  create  or  destroy  pro  esses  after  system 
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Figure  7.  Active  Process  Table 


veneration,  the  initial  entries  into  the  APT  will  he  active 
for  the  life  of  the  system.  The  index  into  the  AFT  is  the 
PROCESSED. 

The  traffic  controller  uses  the  PRIORITY  field  of 
the  APT  to  determine  which  process  to  schedule  for  execution 
on  each  virtual  processor.  The  STATE  field  contains  that 
process"  current  state  (running,  blocked,  or  ready).  The  DPR 
(descriptor  base  register^  field  of  the  APT  provides  the 
address  of  the  MMU  image  for  that  process.  The  Mext_P.eady_.AF 
field  is  a  pointer  which  contains  the  index  of  the  next 
process  which  is  in  the  ready  state. 

The  design  simplification  choice  of  always  having  a 
process  running  on  the  virtual  processors,  introduced  the 
notion  of  an  idle  process  for  each  virtual  processor.  The 
idle  process  is  loaded  onto  a  virtual  processor  and  placed 
into  the  runnirg  state  whenever  the  number  of  available 
virtual  processors  exceeds  the  number  of  ready  or  running 
processes  (excluding  the  idle  process).  The  idle  process  is 
o*  the  lowest  priority,  and  will  only  run  if  nc  othpr 
process  can  be  loaded.  It  is  incapable  of  blocking  itself, 
and  thus  must  always  be  in  either  the  running  or  ready 
s  ta  te . 

When  a  virtual  processor  becomes  available,  the 
traffic  controller  will  be  invokei  to  schedule  the  highest 
priority  ready  process  which  mav  run  on  that  particular 
virtual  processor.  If  no  process  is  ready,  the  Idle  nrccess 
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is  scheduled.  The  Idle  process  provides  a  means  to  puarantee 
that  a  ready  process  will  always  he  found,  and  that  the 
Traffic  Controller  cannot  he  exited  without  scheduling  a 
process . 

5.  Inner  Traffic  Controller 

The  purpose  of  the  inner  traffic  controller  is  to 
provide  the  multiplexing  of  the  virtual  processors  onto  the 
actual  system  processor(s) ,  and  to  provide  the  kernel 
primitives  for  Inter-process  communication  within  the  kernel 
(Signal  and  "sit).  In  the  SASS  design,  each  physical 
processor  has  a  fixed  set  of  virtual  CPU's  that  it 
multiplexes.  The  primary  data  base  utilized  by  the  inner 
traffic  controller  is  the  Virtual  Processor  Table  fVPT'. 
Figure  5  provides  an  example  of  the  VPT. 

The  7^  is  indexed  by  the  Virtual^Processor^IT .  The 
P5P. ,  PHI,  and  the  STATS  fields  are  used  in  the  same  manner 
as  those  fields  in  the  APT.  The  Idle^Ilae  simply  indicates 
that  the  idl®  process  is  loaded  on  that  virtual  crocessor. 
The  Preempt  flap  indicates  that  a  virtual  preempt  interrupt 
has  been  directed  to  that  virtual  processor.  The 
?hys_Frooessor  is  a  fixed  field  that  indicates  which 
hardware  processor  that  virtual  processor  is  scheduled  to 
run  on.  The  Nex t_?eady_V?  is  a  pointer  to  the  index  cf  the 
next  ready  virtual  processor  in  the  VPT  for  this  C?n. 

In  his  ’.riginal  design,  Coleman  [3]  tasked  the  inner 


traffic  controller  with  the  management  of  the  hardware 
Memory  Management  Units  (which  contain  the  process'  address 
space  and  its  attributes)  and  the  MMU  software  images.  In 
the  present  design,  this  function  has  been  assigned  to  the 
memory  manager.  When  the  inner  traffic  controller  unloads  a 
processor,  it  simply  writes  the  MMU  into  the  MMU  image  in 
order  to  save  the  segment  usage  information.  To  load  a 
orocess,  it  writes  the  MMU  image  into  the  MMU.  The  memory 
manager  insures  that  the  MMU  image  is  kept  current  by 
updating  the  images  whenever  a  segment  is  swapped  in  or 
swapped  out  of  memory. 

The  kernel  synchronization  primitives  of  SIGNAI  and 
’''AIT  are  maintained  within  the  inner  traffic  controller. 
These  primitives  are  used  by  virtual  processors  within  the 
kernel  domain  to  synchronize  with  other  virtual  processors 
within  the  kernel  domain. 

T.  NON-IISTBIKJTTE  K-FNUl 

The  SASS  non-dis tributed  kernel  is  composed  solely  cf 
the  memory  manager  process.  ?ach  physical  processor  has 
associated  with  it,  its  cvn  dedicated  memory  manager 
process.  The  purpose  of  the  process  is  the  proper  ar.d  secure 
management  of  the  main  memory  (both  local  and  global),  and 
secondary  storage.  The  actual  transfer  of  segments  from  rain 
memory  to  secondary  storage  and  vice-versa,  is  controlled  by 
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the  memory  manager  process.  The  primary  data  base  utilized 
by  the  process  is  the  Active  feenent  Table.  Chapter  3 
provides  a  detailed  description  of  the  process'  functions 
and  data  bases. 
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MEMORY  MANAGER  PROCESS  DETAILED  DESIGN 


A.  INTRODUCTION 

The  memory  manager  is  responsible  for  the  management  of 

both  main  memory  (local  and  global)  and  secondary  storage. 

It  is  a  non-distributed  portion  of  the  kernel  with  one 

memory  manager  process  existing  per  physical  processor.  The 

memory  manager  is  tasked  (via  signal  and  wait)  to  nerform 

memory  management  functions  on  behalf  of  other  processes  in 

the  system.  The  major  tasks  of  the  memory  manner  are  :  1) 

the  allocation  and  deallocation  of  secondary  storage,  2)  the 

allocation  ar.d  deallocation  of  global  and  local  memory,  3) 

segment  transfer  from  local  to  global  memory  (and  vice 

versa),  ar.d  4)  segment  transfer  frcm  secondary  storage  to 

main  memory  (and  vice  versa).  There  are  ten  service  calls 

(via  signal)  which  task  the  memory  manager  Process  to 

perform  these  functions.  The  tea  service  calls  arei 

CREATE  ENTRY 
DELETE-ENTRY 
ACTIVATE 
DEACTIVATE 
SWA?  IN 
SWA? ’OUT 
DEACTIVATE  All 
MOVE  TO  GLOPAL 

vove’tc"local 

UPDATE 

Upon  completion  of  the  service  request,  the  memory  manager 
returns  The  results  of  the  operation  to  the  waiting  process 
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(via  signal).  It  then  blocks  itself  until  it  is  tasked  to 
perform  another  service.  The  hardware  configuration  managed 
by  the  memory  manager  process  is  depicted  in  figure  9.  The 
shared  data  bases  used  by  all  memory  manager  processes  are 
the  Global  Active  Segment  Table  (G_AST ) ,  the  Alias  Table, 
the  Disk  Bit  Map,  and  the  C-lobal  Memory  Bit  Map.  The 
processor  local  data  bases  used  by  each  process  are  the 
local  Active  Segment  Table  (L_ASTi.  the  Memory  vanagemer.t 
'Jnit  Images  and  the  Local  Memory  Bit  Map. 

F.  DESIGN  ?ARAMBTiRS  AND  DECISIONS 

Several  factors  were  identified  during  the  design  of  the 
memory  manager  process  that  refined  the  initial  kernel 
design  of  Coleman  [o].  The  two  areas  that  were  modified,  vere 
the  management  of  the  MMU  images  and  the  management  of  core 
memory.  Both  of  these  functions  were  managed  outside  of  the 
memory  manager  in  the  initial  design.  The  inclusion  of  these 
functions  in  the  memory  manager  process  significantly 
improved  the  logical  structure  of  the  overall  system  design. 
Additional  design  parameters  were  established  to  facilitate 
the  initial  implementation.  These  design  parameters  reed  to 
he  addressed  before  the  detailed  design  of  the  memory 
manager  process  is  presented. 

It  was  decided  to  make  the  block/page  size  of  both  main 
memory  and  secondary  storage  equal  in  size.  This  was  to 
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simplify  the  rapping  algorithm  from  secondary  storage  to 
main  memory  (and  vice  versa).  In  the  initial  design  the 
block/page  size  was  set  to  512  bytes. 

The  sizp  of  the  pare  table  for  a  segment  was  set  at  one 
page  (non-paged  page  table).  This  was  to  simplify 
implementation,  and  had  a  direct  bearing  on  the  maximum 
segment  size  supported  in  the  memory  manager.  For  example,  a 
page  size  of  256  bytes  will  address  a  maximum,  segment  size 
of  32,758  bytes,  while  a  page  size  of  512  bytes  will  address 
a  segment  size  of  131,072  bytes. 

The  size  o'*  the  alias  table  was  set  to  one  pare 
(non-paged  alias  table).  The  number  of  entries  that  the 
alias  table  will  support  is  limited  by  the  size  of  the  page 
table  (viz.,  a  page  size  of  512  bytes  will  support  up  to  46 
entries  in  the  Alias  Table). 

In  the  original  design,  the  main  memory  allocation  was 
external  to  the  memory  manager.  This  was  due  to  the 
oartitioned  memory  management  scheme  outlined  by  Parks  [2] 
and  Coleman[3).  In  the  current  design,  all  address 
assignment  and  segment  transfer  are  managed  by  the  rernory 
manager.  This  design  choice  enhanced  the  generality  of  the 
design,  and  nrcvided  support  for  any  memory  management 
scheme  (either  in  the  memory  manager  or  at  a  higher  level  of 
abstraction'.  However,  the  current  design  still  has  a 
maximum  core  constraint  for  each  process. 
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Dynamic  memory  management  is  not  implemented  in  this 
design.  Each  process  is  allocated  a  fixed  size  of  physical 
core.  Fovever,  it  is  not  a  linear  allocation  of  physical 
memory.  The  design  supports  the  maximum  sharing  of  segments 
in  local  and  Global  memory.  All  segments  that  are  not 
shared t  or  shared  and  do  not  violate  the  readers /writers 
problem  will  reside  in  local  memory  to  eliminate  the  global 
bus  contention.  The  need  to  compact  the  memory  (because  of 
fragmentation)  should  be  minimal  in  this  design  due  tc  the 
maximum  sharing  of  segments.  If  contiguous  memory  is  not 
available,  the  memory  manager  will  compact  main  nerory. 
After  compaction,  the  memory  can  be  allocated. 

The  design  decision  to  represent  memory  as  one 
contiguous  block  (not  partitioned)  was  made  to  support  a 
dynamic  memory  management  scheme.  Without  dynamic  memory 
management,  the  process'  total  physical  memory  can  not 
exceed  the  systems  main  memory.  The  supervisor  knows  the 
size  of  the  segments  and  the  size  o?  the  process'  virtual 
core,  therefore  it  can  manage  the  swap  in  and  swan  out  to 
ensure  that  the  process'  virtual  core  has  not  been  exceeded. 

In  the  original  design,  the  user's  process  inner-traffic 
controller  maintained  the  software  images  of  the  memory 
management  unit.  This  design  required  the  memory  manager  to 
return  the  appropriate  memory  management  data  (viz . .segment 
location)  to  the  kernel  of  the  user's  process.  In  the 
current  design,  the  software  images  of  the  MMU  are 
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maintained  b y  the  memory  manager.  A  descriptor  base  pointer 
is  provided  for  the  inner-traffic  controller  to  multiplex 
the  process  address  spaces.  The  PM'T  image  data  base  does  not 
need  t.o  he  locked  (to  prevent  race  conditions)  due  to  the 
fact  that  process  interrupts  are  masked  in  the  kernel.  Thus, 
if  the  memory  manager  (a  kernel  process)  is  running  then  no 
other  process  can  access  the  MMU  image. 

The  system  initialization  process  has  not  been  addressed 
to  date.  However,  this  design  has  made  some  assumptions 
about  the  initial  state  of  the  system.  Since  the  memory 
manager  handles  the  transfer  of  segments  from  secondary 
storage  to  main  memory,  it  is  likely  to  be  one  of  the  first 
processes  created.  The  memory  manager's  core  image  will 
consist  of  its  pure  code  and  data  sections.  The  minimal 
initialization  of  the  memory  manager's  data  bases  are 
entries  for  the  system  root  and  the  supervisor's  segments  in 
the  G_AST  and  I_4ST(s),  and  the  initializaton  of  the  PKfJ 
images  with  the  kernel  segments.  The  current  design  does  not 
call  for  an  entry  in  the  5_AST  or  t_AST  for  the  kernel 
segments.  However,  when  system  generation  is  designed  this 
will  have  to  be  readdressed. 

The  original  [3]  memory  manager  data  bas«s  have  been 
refined  by  this  thesis  to  facilitate  the  memory  management 
functions.  The  major  refinements  of  the  global  and  local 
active  segment  tables  are  outlined  in  the  following  section. 
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C.  TATA  BASES 


1 .  Global  Active  Segment  Table 

The  Global  Active  Segment  Table  (see  figure  1?'  is  a 
system  wide,  shared  data  base  used  by  memory  manager 
processes  to  manage  all  active  segments.  A  lock/unlock 
mechanism  is  utilized  to  prevent  any  race  conditions  from 
occurring.  The  signalling  process  locks  the  G_AST  before  it 
signals  the  memory  manager.  This  is  done  to  prevent  a  deadly 
embrace  from  occurring  between  memory  manager  processes,  and 
also  to  simplify  synchronization  between  memory  managers. 
The  entire  G_AST  is  locked  in  this  design  to  simplify  the 
implementation  (vice  locking  each  individual  entry's. 

The  G_AST  size  is  fixed  at  compile  time.  The  size  of 
the  G_AS?  is  the  product  of  the  G_AST  record  size,  the 
maximum  number  of  processes  and  the  number  of  authorized 
known  segments  per  process.  Although  the  G_AST  is  of  fixed 
size,  it  is  plausible  to  dynamically  manage  the  entries  as 
proposed  bv  Bichardson  and  0 'Connell  [l]  .  The  current  memory 
manager  design  could  be  extended  to  include  this  dynamic 
management . 

The  Unique_Id  field  is  a  unique  segment 
identification  number  in  the  G_AST.  This  field  is  four  bytes 
wide  and  will  provide  over  four  billion  ider.tif icaticn 
numbers.  A  design  choice  was  made  not  to  manage  the 
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Figure  10.  Global  Active  Segment  Table. 
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reallocation  of  the  unique^ia 's .  Thus  when  a  seiner t  is 
deleted  from  the  system,  the  unique_id  is  not  reused. 

The  Global_Address  field  is  used  to  indicate  if  a 
segment  resides  in  global  or  local  memory.  If  not  r.ull,  it 
contains  the  Global  memory  base  address  of  a  segment.  A  null 
entry  indicates  that  the  segment  might  be  in  local 
memory( si . 

The  ?rocessors_I_ASTS_#  field  is  used  as  a  connected 
processors  list.  The  field  is  an  array  structure,  indexed  by 
?rocessor_Id .  It  identifies  which  L_AST  the  segment  is 
active  in,  and  provides  the  index  into  each  of  these  tables. 
The  design  choice  of  maintaining  an  entry  in  the  L_AST  for 
all  locally  active  segrents  implies  that  if  all  entries  in 
the  ?rocessors_I_AST2_#  field  are  null,  the  segment  is  not 
active  and  can  be  removed  from  the  G_AST  (viz.,  no 
processors  are  connected). 

The  Flag_Bits  fi^ld  consists  of  the  written  bit,  and 
the  writable  tit.  The  written  bit  is  set  when  a  segment  is 
swapped  out.  cf  memory,  and  the  yMTT  image  indicates  that  it 
has  been  written  into.  The  writable  bit  is  set  during 
segment  loading  to  indicate  that  some  process  has  write 
access  to  that  segment. 

If  an  active  segment  is  a  leaf,  the  G_A$T3_#_?arer.t 
field  provides  a  back  pointer  to  the  G_AST  index  of  its 
parent.  This  back  pointer  to  the  parent  is  important  during 
the  creation  of  a  segment.  If  a  request  is  received  to 
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create  a  segment  which  has  a  leaf  segment  as  its  parent, 
then  an  alias  table  has  to  he  created  for  that  parent.  Also, 
the  alias  table  of  the  parent's  parent  needs  to  be  updated 
to  reflect  the  existence  of  the  newly  created  alias  table 
(see  figure  11).  The  indirect  pointer  shown  is  the  back 
pointer  to  the  parent  via  the  G_A?T. 

The  No_Ac tive_In_Memory  field  is  a  count  of  the 
number  of  processes  that  have  the  segment  in  elooal  memory. 
It  is  used  during  swap  out  to  determine  if  the  segment  can 
be  removed  from  global  memory. 

The  No_>Active_Eependents  field  is  a  count  of  the 
number  of  active  leaf  segments  that  are  dependent  on  this 
entry  (viz.,  require  that  this  segment  remain  in  the  G_AST). 
Sach  time  a  process  activates  or  deactivates  a  dependent 
segment  this  field  is  incremented  or  decremented. 

The  Size  field  is  the  size  of  the  segment  in  bytes. 
The  ?age_Table_location  field  is  the  disk  location  of  the 
cage  table  for  a  segment,  ar.d  the  Alias_Table_Iocatior  field 
is  the  disk  location  of  the  alias  table  for  the  segment.  The 
Alias_Tahl»  field  car.  be  null  tc  indicate  that  no  alias 
table  exists  for  the  segment. 

The  last  three  fields  are  used  in  the  management  of 
eventscunts  and  sequencers  f4] .  The  Sequencer  field  is  used 
to  issue  a  service  number  for  a  segment.  The  Ir.star.ce_l 
field  and  Ir.stance_2  field  are  eventcounts  (i.e.,  are  used 
to  indicate  the  next  number  of  occurances  of  some  event). 
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Figure  11.  Alias  Table  Creation. 


2.  Local  Active  Segment  Table 


The  local  Active  Segment  Table  (see  figure  12)  is  a 
processor  local  data  base.  The  L_AST  contains  the 
characteristics  (viz.,  segment  number,  access)  of  each 
locally  active  segment.  An  entry  exists  for  each  segment 
that  is  active  in  a  process  "loaded"  on  this  CPU  and  in 
local  memory.  The  first  field  of  the  L_AST  contains  the 
memory  address  of  the  segment.  If  the  segment  is  not  in 
memory,  this  field  is  used  to  indicate  whether  the  t_AST 
entry  is  available  or  active.  The  Segment_.No/Access  field  is 
a  combination  of  segment  number  and  authorized  access.  It  is 
an  array  of  records  data  structure  that  is  indexed  by  D3R_*. 
The  first  record  element  (viz. .most  significant  bi t A  is  used 
to  indicate  the  access  (read  or  read/write)  Permitted  to 
that  segment.  The  second  record  element  (viz.,  the  next 
seven  bits)  is  used  to  indicate  the  segment  number.  A  null 
segment  number  Indicates  that  the  process  does  not  have  the 
segment  active. 

3.  Alias  Table 

The  alias  table  (see  figure  13'  is  a  memory  manager 
data  base  which  is  associated  with  each  non  leaf  segment  in 
the  kernel.  An  aliasing  scheme  is  used  to  prevent  passing 
systemwide  information  (uniqua_id.)  out  of  the  kernel. 
Segments  can  only  be  created  through  a  mentor  segment  and 
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Figure  13.  Alias  Table. 
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entry  number  into  the  mentor's  alias  table.  When  a  segment 
is  created,  an  entry  must  be  made  in  its  mentor  segment's 
alias  table.  Thus  the  mentor  segment  must  be  known  before 
that  segment  can  be  created. 

The  alias  table  consists  of  a  header  and  an  array 
structure  of  entries.  The  header  has  two  "pointers’  fvi?., 
disk  addresses),  one  that  links  the  alias  table  to  its 
associated  segment  and  one  that  links  the  alias  table  to  the 
mentor  segment's  alias  table.  The  header  is  provided  to 
support  the  re-coastruc tion  of  the  file  system  after  a 
system  crash  due  to  device  I  ‘0  errors.  It  is  not  used  at  all 
during  normal  operations  S.ch  entry  in  the  array  structure 
consists  n?  five  fields  for  identifying  the  created 
segments.  The  Unique.Id  field  contains  tr.e  unique 
identification  number  for  the  se,  'nt.  The  Size  field  is 
used  to  record  the  size  of  the  segment.  The  Class  field 
contains  the  appropriate  security  access  class  of  the 
segment.  The  Page_Table_Locatior.  field  has  the  disk  address 
of  the  pa«?e  table.  A  null  entry  indicates  a  zero-length 
segment.  The  Alias  JTaMeJlocation  field  has  the  disk  address 
of  the  alias  table  for  the  segment.  A  null  entry  indicates 
that  the  segment  is  a  leaf  segment. 

4.  Memory  management  Unit  Image 

The  Memory  Management  Unit  Imaze  (MMU_In*ege)  is  a 
processor  local  data  base.  It  is  an  array  structure  that  is 
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irdexed  by  the  B3R_*.  Sach  MMTJ_Inage  (see  figure  14) 
includes  a  software  representation  of  the  segment  descriptor 
registers  (SDR)  for  the  hardware  MMU  [12].  This  is  in 
exactly  the  format  used  hy  the  special  I/O  instructions  for 
1  oadlng/unloading  the  MM'J  hardware.  The  SDR  contains  the, 
Fase^Address ,  limit  and  Attribute  fields  for  each  loaded 
segment  in  the  process'  address  soace.  The  Fase_Address 
field  contains  the  base  address  of  the  segments  in  memory 
(local  or  global).  The  limit  field  is  the  number  of  blocks 
of  contiguous  storage  for  each  segment  (zero  indicates  one 
block).  The  Attribute  field  contains  eight  flags.  Five  flags 
are  us#d  for  protecting  the  segment  against  certain  tvpes  of 
access,  two  encode  the  type  of  accesses  made  to  the  segment 
(read/write),  and  one  indicates  the  special  structure  of  the 
segment  [1?)  .  Five  of  the  eight  flags  in  the  attribute  field 
are  used  by  the  memory  manager.  The  "system  only"  and 
"execute  onlv"  flags  are  used  to  protect  the  code  of  the 
Vern&l  from  malicious  or  unintentional  modifications.  The 
"read  only"  flag  is  used  to  control  the  read  or  write  access 
tc  a  segment.  The  "change"  flag  is  used  to  indicate  that  the 
segment  has  been  written  into,  and  the  "C?U-ir.hibit"  flag  is 
used  to  indicate  that  the  segment  is  not  in  memory. 

The  last  two  fields  of  the  MMU_Image  are  the 
Rlock_TJsed  field  and  the  N'aximum_Available_?lccks  field. 
These  two  fields  are  used  in  the  mangement  of  each  process' 
virtual  core  and  are  not  associated  with  tne  hardware  yPU. 
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Figure  14.  Memc?y  Management  Unit  Image 
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5.  Memory  Allocation/Deallocation  Bit  Maps 


All  of  the  memory  allocation/deallocatior  hit  maps 
(see  figure  15'  are  basically  the  same  structure.  Secondary 
storage,  global  memory  and  local  memory  are  managed  by 
memory  bit  maps.  The  Disk_Bit_Map  is  a  global  resource  that, 
is  protected  from  race  conditions  via  the  locking  convention 
for  the  G_AST.  Fach  bit  in  the  bit  map  is  associated  with  a 
block  of  secondary  storage.  A  zero  indicates  a  free  block  of 
storage  while  a  one  indicates  an  allocated  block  of  storage. 
The  Global^emory^Ii t_^ap  is  used  to  manage  global  memory. 
It  is  a  shared  resource  that  is  protected  from  race 
conditions  by  the  locking  of  the  G_AST.  The 

local  J*emory_BitJ*ap  is  the  same  structure  as  the 
Global_vemoryJEit_Map  and  is  used  to  manage  local  memory. 
The  LocalJ^emory^Si t^Kap  is  not  locked  since  it  is  not  a 
shared  resource  between  memory  managers. 

C.  BASIC  FUNCTIONS 

The  detailed  source  code  for  t  'e  basic  functions  and 
main  line  of  the  memory  manager  are  presented  ir.  appendices 
A  and  B.  Appendix  A  lists  the  procedures  which  are  coded  ir. 
PIZ/SY^,  while  Appendix  p  lists  the  lower  level  hardware 
dependent  procedures  which  are  code*’  in  PLZ/ASM. 

PIZ/SYS  is  a  high  level  modular  structured  language 
which  produces  a  machine-independent  Z-code  similar  to 
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PASCAL'S  F-code.  The  translator  from  Z-^ode  to  Z-S000 
machine  code  is  currently  under  development  at  ZIIOG  Inc., 
thus  the  PLZ/STS  module  could  not  he  compiled  on  the  ZP000 
[13] .  PLZ/ATM  is  a  symbolic  assembly  language  that  is  used 
to  program  the  Z-8000.  The  assembler  supports  Structured 
programming  and  produces  a  relocatable  Z-8000  object  module. 

In  the  discussion  of  the  memory  manager  design,  a 
pseudo-code  similar  to  PLZ/SYS  is  utilized.  The  rationale 
for  using  this  pseudo-code  was  to  provide  a  summary  of  the 
memory  manager  source  code,  and  to  facilitate  the 
presentation  of  this  design. 

It  is  assumed  that  the  memory  manager  is  initialized 
into  the  ready  state  at  system  generation  (as  previously 
mentioned).  When  the  memory  manager  is  initially  placed  into 
the  running  state,  it  will  block  itself  (via  a  call  to  the 
kernel  primitive  Wait).  Wait  will  return  a  message  from  a 
signalling  process.  This  message  is  interpreted  by  the 
memory  manager  to  determine  the  requested  function  ar.d  its 
required  arguments.  The  function  code  is  used  to  enter  a 
case  statement,  which  directs  the  request  to  the  appropriate 
memory  manager  procedure. 

When  the  requested  action  is  completed,  the  memory 
manager  returns  a  success  code  (and  any  additional  required 
data)  the  signalling  process  via  a  call  to  the  kernel 
primitive  Signal.  This  call  will  awaken  the  process  which 
requested  the  action  to  be  taken,  and  place  the  returned 
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message  Into  that  process'  message  queue.  When  that  action 
is  completed,  the  memory  manager  will  return  to  the  top  of 
the  loop  structure  and  block  itself  to  wait  for  the  the  next 
request.  The  main  line  pseudo-code  of  the  memory  manager 
process  is  displayed  ir.  figure  16. 

1.  Create  an  Alias  Table  Entry 

Create_Entry  is  invoiced  when  a  user  desires  to 
create  a  segment.  A  segment  is  created  hy  allocating 
secondary  storage,  and  hy  making  an  entry  (unique_id, 
secondary  storage  location,  size,  classification)  into  it's 
mentor  segment's  alias  table.  This  implies  that  the  mentor 
segment  must  have  an  alias  table  associated  with  it,  and 
that  the  mentor  segment  must  be  active  in  order  to  obtain 
the  secondary  storage  location  of  the  alias  table. 

The  mentor  segment  can  be  in  one  of  two  states.  It 
may  have  children  (viz.,  have  an  alias  table',  or  it  may  be 
a  leaf  segment  (viz.,  not  have  an  alias  table).  If  the 
mentor  segment  has  children,  it  has  an  alias  table  and  this 
alias  table  can  be  read  into  core,  secondary  storage  can  be 
allocated,  and  the  data  can  be  entered  into  the  alias  table. 
If  the  mentor  segment  is  a  leaf,  an  alias  table  must  be 
created  for  that  segment  before  it  (the  alias  table)  can  be 
read  into  core  and  data  entered  into  it  (see  figure  11). 

The  pseudo-code  for  caSAT3_SNTF.T  FR0CEEUH3  is 
presented  in  figure  l?,.  The  arguments  passed  to  Create_Er.try 
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ENTRY 

INITIALIZE  PROCESSOR  LOCAL  VARIABLES 
DO  “ 

!  CHECE  IF  MSG  QUEUE  EMPTY  ! 

VP  ID,  MSG  7=  WAIT 

FUNCTION,  ARGUMENTS  :  =  VALIDATE  MSG  (MSG) 

IF  FUNCTION 

CASE  CREATE  ENTRY  THEN 

SUCCESS  CODE  :=  CREATE  ENTRY  (ARGUMENTS) 
CASS  DELETE  ENTRY  THEN 

success  Code  :=  delete  entry  (arguments) 

CASE  ACTIVATE  THEN 

SUCCESS  CODE  :=  ACTIVATE  (ARGUMENTS) 

CASE  DEACTIVATE  THEN 

SUCCESS  CODE  :=  DEACTIVATE  (ARGUMENTS) 

CASE  SWAP  IN  THEN 

SUCCESS  CODE  :*  SWA?  IN  (ARGUMENTS) 

case  swa?  Cut  then 

SUCCESS  CODE  :=  SWAP  OUT  (ARGUMENTS) 

CASE  DEACTIVATE  ALL  THEN 

SUCCESS  CODE":=  DEACTIVATE  AIL  ( ARGUMENTS ' 
CASS  MOVE  TO  GLOBAL  THEN 

SUCCESS  CODE  :*  MOVE  TO  GLOBAL  ( ARGUMENTS ) 
CASE  MOVE  TO  LOCAL  THEN 

SUCCESS  CODE  :=  MOVE  TO  LOCAL  (ARGUMENTS) 
CASE  UPDATE  THEN 

SUCCESS  CODE  :=  UPDATE  (ARGUMENTS) 

FI 

SIGNAL  (VP  ID,  SUCCESS  CODE,  ARGUMENTS) 

cr 

END  MEMORY  MANAGER  PI 2 /SYS  MODULE 


Figure  16.  Memory  Manager  Mainline  Code. 
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CHEATS  ENTRY  PROCEDURE  (FAR  INDEX  WORD  *  ENTRY  #  WORD, 

SIZE  WORD,  CLASS  "BYTE) 

RETURNS  (SUCCESS  CODE  BYTE) 

LOCAL  ELKS  WORD,  PACE  TABLE  LOC  WORD 
ENTRY 

IF  ALIAS  TABLE  DOES  NOT  EXIST  THEN 
SUCCESS  CODl  :=  CREATE  ALIA?  TABLE 
IF  SUCCESS  CODE  O  VALID  THEN  RETURN 
FI 
FI 

BLKS  :=  CALCULATE  NO  BLKS  REQ  (SIZE) 

SUCCESS  CODE  :=  READ^ALIAS  TABLE  ( 

G  AST [PAR’INDSX] .ALIAS  TABLE  IOC) 

IF  SUCCESS  CODE  <>  VALID  THEN  RETURN 
FI 

SUCCESS  COTE  :=  CHECK  DUP  ENTRY  !  in  alias  table  ! 

IF  SUCCESS  CODE  O  VALID  THEN  RETURN 
FI 

SUCCESS  CODE,  PAGE  TABLE  LOC  :=  ALLOC  SEC  STORAGE  (BLKS) 
IF  SUCCESS  CODE  O  VALID  THEN  RETURN 
FI 

UPDATE  ALIAS  TABLE (ENTRY  #,  SIZE,  CLASS,  FACE  TABLE  ICC ' 
SUCCESS  C0LS~:=  WRITE  ALIAS  TABLE  ( 

G  ASTIpAR  INDEX] .ALIAS  TAPIS  LOC) 
IF  SUCCESS  CODE  <>  VALID  THEN  RETURN 
ELSE  SUCCESS  CODE  :=  SEG  CREATED 
FI 

END  CREATE  ENTRY 


Figure  17.  Create  Entry  Fseudo-code . 
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are  the  index  into  the  G_AST  for  the  mentor  segment,  the 
entry  number  into  its  alias  table,  the  size  of  the  segment 
to  be  created,  and  the  security  access  class  of  that 
segment.  The  return  parameter  is  a  success  code,  which  would 
be  "seg_created"  for  a  successful  segment  creation. 

When  invoked,  CreateJSntry  will  determine  which 
state  the  mentor  segment  is  in  (viz.,  if  it  has  an  alias 
table).  If  an  alias  table  does  not  exist  for  the  mentor 
segment,  one  is  created  and  the  alias  table  of  the  mentor 
segment's  parent  is  updated.  The  alias  table  is  read  into 
core  and  a  duplicate  entry  check  is  made.  If  no  duplicate 
entry  exists,  the  segment  size  is  converted  from  bytes  to 
blocks,  and  the  secondary  storage  is  allocated,  for  non-zero 
sized  segments.  The  appropriate  data  is  entered  into  the 
alias  table  and  the  alias  table  is  then  written  back  to 
secondary  storage. 

2.  Delete  an  Allas  Table  Entry 

Delete_Sntry  is  invoked  when  a  user  desires  to 
delete  a  segment.  A  segment  is  deleted  by  deallocating 
secondary  storage,  and  by  removing  the  appropriate  entry 
from  the  alias  table  of  its  mentor  segment  (the  reverse 
logic  of  CreateJSntry).  This  implies  that  the  mentor  segment 
must  be  active  at  the  time  of  deletion.  There  are  three 
conditions  that  can  be  encountered  during  the  deletion  of  a 
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segment:  the  segment  to  be  deleted  may  be  an  inactive  leaf 
segment,  an  active  leaf  segment,  or  a  mentor  segment. 

If  the  segment  to  be  deleted  is  an  inactive  leaf 
segment  (viz.,  has  been  swapped  out  of  core,  and  does  not 
have  an  entry  in  the  G_AST),  the  secondary  storage  can  be 
deallocated  and  the  entry  deleted  from  the  mentor  segment's 
alias  table.  If  the  segment  is  an  active  leaf  segment,  the 
segment  must  first  be  swapped  out  of  core  and  deactivated 
before  it  can  be  deleted.  This  entails  signalling  the  memory 
manager  of  each  processor,  in  which  the  segment  is  active, 
to  swap  out  and  deactivate  the  segment. 

If  the  segment  to  be  deleted  is  a  mentor  segment,  an 
alias  table  exists  for  that  segment  .  If  the  alias  table  is 
empty,  the  secondary  storage  for  the  alias  table  and  the 
segment  car  be  deallocated,  and  the  entry  for  the  deleted 
segment  can  be  removed  from  its  mentor's  alias  table.  If  the 
alias  table  contains  any  entries,  the  segment  cannot  be 
deleted  because  these  entries  would  be  lost.  If  this 
condition  is  encountered  ;»  success  code  of 
"leaf^segment^exis ts "  is  returned  to  the  process  which 
requested  to  delete  the  entry.  Due  to  a  confinement  problem 
in  "upgraded"  segments,  this  Success_code  cannot  always  be 
passed  outside  of  the  kernel.  This  implies  that  the  segment, 
manager  must  strictly  prohibit  deletion  of  a  segment  with  an 
access  class  not  equal  to  that  of  the  process. 
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The  pseudo-code  for  mETE_ENTRY_PRCCEms  is 
presented  in  figure  16.  The  parameters  that  are  passed  to 
this  procedure  are  the  parent's  index  into  the  G_AST  and  the 
entry  number  into  the  parent's  alias  table  of  the  segment  to 
b?  deleted.  The  alias_table_loc  field  is  checked  to 
determine  the  state  of  the  mentor  segment  (either  a  leaf  or 
,?  node),  and  the  appropriate  action  is  then  taken.  A  success 
code  is  returned  to  indicate  the  results  of  this  procedure. 

3.  Activate  a  Segment 

Activate  is  invoked  when  a  user  desires  to  make  a 
segment  known  by  adding  a  segment  to  his  address  space.  A 
segment  is  activated  by  making  an  entry  into  the  L_AST  for 
that  processor,  and  the  G_AST.  The  activated  segment  could 
be  in  one  of  three  states?  it  could  have  previously  been 
activated  by  another  process  and  have  a  current  entry  in 
both  the  G_AST  and  L_AST,  it  could  have  previously  been 
activated  by  another  process  on  a  different  processor  and 
have  an  entry  in  the  G_AST  but  not  the  t_AST,  or  it  could  be 
inactive  and  have  an  entry  in  neither  the  G_AST  nor  the 
LJtST. 

If  the  segment  to  be  activated  already  has  entries 
in  both  the  L_AST  and  G_A5T ,  these  entries  need  only  be 
updated  to  Indicate  that  another  process  has  activated  the 
segment.  The  segment  number  is  entered  into  the 
Segment_No/Acce ss^Auth  field  of  the  l_AST,  and  if  the 
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DELETE  FMTST  PROCEDURE  (  PAR  INDEX  WORE,  ENTRY  #  WORD  ) 
RETURNS  (SUCCESS  CODE  BITE) 

LOCAL  PAR  INDEX"  WORD 
ENTRY 

!  Check  if  the  passed  mentor  segment  has  an  alias  table. 
IE  G  AST[PAF  INDEX] .ALIAS  TABLE  LOC  O  NULL 
SUCCESS  CODE  :=  READ  ALIAS  TABLE  ( 

g  ast [par  Index] .alias  table  log) 

ELSE  " 

SUCCESS  CODE  :=  NO  CHILD  TO  DELETE 
FI  "  ~ 

IF  SUCCESS  CODE  O  VALID  THEN  RETURN 
FI 

!  Determine  if  segment  has  children  in  alias  table  ! 

IF  ALIAS  TABLE  NOT  EMPTY  THEN 

SUCCSS$_COBE  :="LEAF_SEGMENT_SXI$TS 
RETURN  !  Deletion  will  delete  children  ! 

ELSE 

!  Search  G  AST  with  UNIQUE  ID  to  verify  segment  inactive  l 
IF  "ACTIVE  IN  r-  AST"  THEN 

’  Check  if  active  in  AST  ! 

IF  ACTIVE  IN  L  AST  THEN 

DEACTIVATE  ALL  (G  AST  INDEX,  L  AST  INDEX) 

n  “  " 

!  Check  G  AST  to  verify  segment  inactive  in  other  I  AST's 
"  IF  ACTIVE  IN  OTHER  L  AST  THEN 

SIGNAL”T0“DEACTTVATE  ALL  (G  AST  INDEX) 

FI  ~  "  ~  " 

FI 

F?FE_SEC  STORAGE  OF  SSG  <5,  ALIAS  IF  EXISTS 
DEISTS  ALIAS  TABLE  ENTRY  ~ 

FI 

DELFTE  AIIAS  TABLE  FNTRY 

SUCCESS  CODE":*  WRITS  ALIAS  TABIS  ( 

G  AST [FAR"lNDEX] .ALIAS  TABLE  IOC) 

IF  SUCCESS  CODE  =  VALID  TFEN 
SUCCESS  COTE  :=  SEG  DELETED 
FI 

END  DEISTS  ENTRY 


Figure  IS,  Delete  Entry  Pseudo-code. 
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segment  is  a  leaf,  its  mentor's  Nc_Active  JDependents  field 
in  the  G_AST  is  incremented.  In  this  design,  the  G_AST  is 
always  searched  to  determine  if  the  segment  has  been 
previously  activated  hy  another  process. 

If  the  segment  to  he  activated  has  an  entry  in  the 
G_AST  hut  not  the  1_AST,  an  entry  must  he  made  in  the  L_AST 
and  the  G_AST  must  he  updated.  The  L_AST  is  searched  to 
determine  an  available  index.  The  segment  number  is  entared 
into  the  I_A$T ,  and  the  index  number  is  entered  into  the 
G_AST  ?rocessors_L_AST3_#  field.  If  the  segment,  to  he 
activated  is  a  leaf  segment,  its  mentor's 
No_Active_Dependents  field  in  the  G_AST  is  incremented. 

If  the  activated  segment  does  not  have  an  entry  in 
either  the.  G_AST  or  L_AST,  an  entry  must  he  made  in  both. 
The  G_AST  is  searched  to  find  an  available  index,  and  the 
entry  is  made.  The  I_AST  is  then  searched  to  find  an 
available  index,  and  the  entry  is  made.  The  I_AST  index  is 
then  entered  into  the  G_AST  Frocessors_LwAST2_#  field.  If 
the  activated  segment  is  a  leaf,  the  No_Active_rependents 
field  of  its  mentor's  G_AST  entry  is  incremented. 

The  pseudo-code  for  ACTIVATE  PKOCEFUFE  is  presented 
in  figure  19.  The  parameters  that  are  passed  are  the  DFR_# 
of  the  signalling  process,  the  mentor  segment's  index  into 
the  G_A.ST,  the  alias  table  entry  number,  and  the  segment, 
number  of  the  activated  segment.  The  mentor  segment  is 
always  checked  to  determine  if  it  has  an  associated  alias 
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ACTIVATE  PROCEDURE  (DBR  #  BYTE,  PAR  INDEX  WORD, 

ENTRY  #  WORD ,  SEGMENT  NO  BYTE) 
RETURNS  (SUCCESS  CODE  lYTE,  RET  G  AST  RANDLE  RANDLE, 

CLASS  3YTE ,  SIZE  WORD) 

IOCAL  C-  INDEX  WORD,  L  INDEX  WORD 
ENTRY 

!  Verify  that  passed  segment  is  a  mentor  segment  ! 

IE  G  AST  [PAR  TNDEX] .ALIAS  TABLE  LOC  <>  %  THEN 
SUCCESS  CODE  :  =  READ  ALIAS  TABLE  ( 

G  AST[PAR  INDEX) .ALIAS  TABLE  LOC) 
ELSE  "  “ 

SUCCESS  CODE  ;=  ALIAS  DOES  NOT  EXIST 
FI  "  “  " 

IF  SUCCESS  CODE  O  VALID  THEN  RETURN 
FI 

!  Check  G  AST  to  determine  if  active  ! 

SUCCESS-CODS, INDEX  :*  SEARCH  G  AST  (UNIQUE  ID) 

IP  SUCCESS  CODE  «  FOUND  THEN"  " 

I?  SEGMENT  IN  I  AST  THEN 
UPDATE  I  AST"(SSGMSNT  NO) 

EISF 

MAKS  L  AST  ENTRY  (DDE  A,  SEGMENT  NO) 

UPDATS“G  AST  (L  INDEX) 

if  g  astTindex] Talias  tablf  loc  =  null  tffn 

G  AST [PAR  INDEXJ.NO  DEPENDENTS  ACTIVE  *■  1 
FI 
FI 

ELSE 

MAKE  G  AST  ENTRY  (ENTRY  #) 

MAKE*’l'“AST”’L.T?Y  (PAF.  INDEX,  ENTRY 
FI 

SUCCESS  CODE  :=  SEG  ACTIVATED 
END  ACTIVATE 


Figure  19.  Activate  Pseudo-code. 
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table.  If  it  does  not,  the  success  code  of 
"alias_does_not_exist’'  is  returned.  If  the  alias  table  does 
exist,  it  is  read  into  core  and  the  entr,/  number  is  used  as 
an  index  to  obtain  the  activated  segment's  unique_id.  The 
G_AST  is  then  searched  to  determine  if  the  segment  ’  j 
already  been  activated.  If  the  unique_ld  is  found,  the  G_AST 
is  updated  and  the  I..AST  is  either  updated  or  an  entry  is 
made  (depending  on  whether  an  entry  existed  or  not).  If  the 
unique_id  of  the  segment  was  not  found  during  the  search  of 
the  G^AST,  an  entry  must  be  made  in  both  the  G_AST  and 
L_AST.  Activate  returns  the  activated  segment's 
classification,  si2e,  and  handle  to  the  signalling  process. 

4.  Deactivate  a  Segment 

Deactivate  is  invoiced  when  a  user  desires  to  remove 
a  segment  from  his  address  space.  To  deactivate  a  segment, 
the  memory  manager  either  removes  or  updates  an  entry  in 
both  the  L_AST  and  G_AST.  Deactivate  uses  the  reverse  logic 
of  activate.  Once  a  segment  is  deactivated,  it  can  only  be 
reactivated  via  its  mentor's  alias  table  as  discussed  in 
activate.  If  a  process  requests  to  deactivate  a  segment 
which  has  not  been  swapped  out  of  the  process'  virtual  core, 
the  memory  manager  swaps  the  segment  out  and  updates  the 
image  before  the  segment  is  deactivated.  The  segment  to  be 
deactivated  cculd  be  ir.  one  of  three  states}  more  than  ore 
process  could  concurrently  hold  the  segment  active  iu  the 
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L_AST,  the  segment  could  he  held  active  hy  one  process  in 
the  I_AST  and  more  than  one  in  the  G_AST,  the  segment  could 
he  held  active  hy  only  one  process  in  both  the  L_AST  and  the 
G_AST. 

Deactivation  of  leaf  segments  and  mentor  segments 
are  handled  differently.  If  the  segment  is  a  mentor  segment 
and  has  active  dependents,  it  cannot  he  removed  from  the 
G_AST  (even  though  no  process  currently  has  that  segment 
active).  This  is  based  on  the  design  decision  which  requires 
that  the  mentor  of  all  active  leaf  segments  remain  in  the 
G_AST  to  allow  access  to  its  alias  table.  The  mentor's  alias 
table  must  he  accessible  when  an  alias  table  is  created  for 
a  dependent  leaf  segment.  If  a  le=f  segment  is  deactivated, 
the  No_Active_Dependents  field  of  its  mentor's  G_AST  entry 
is  decremented.  A  mentor  segment  can  only  be  removed  from 
the  ^AST  if  no  process  holds  it  active,  and  it  has  no 
active  dependents. 

If  more  than  one  process  concurrently  hold  a  segment 
active  in  the  I.AST,  and  one  of  them  signals  to  deactivate 
that  segment,  the  entry  in  the  1_AST  is  updated.  This  is 
accomplished  by  nulling  out  the  Segment_No/Access_*.uth  field 
of  the  L_AST  for  the  appropriate  process.  If  required,  the 
No_>Active_Dependen ts  field  of  its  mentor  segment's  G_AST 
entry  is  decremented. 
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If  only  one  process  holds  the  segment  active  in  the 
I,_AST ,  and  that  Process  signals  to  deactivate  the  segment  ♦ 
the  L_AST  entry  for  that  segment  is  removed.  The 
Processors_I_ASTE_#  is  updated  and  checked  to  determine  if 
there  are  other  connected  processors.  If  there  are  no  other 
connected  processors  and  the  segment  has  no  active 
dependents,  the  segment  is  removed  from  the  G_AST.  If  there 
are  other  connected  processors,  the  G_AST  is  updated.  If  the 
deactivated  segment  is  a  leaf,  the  mentor  segment's 
No_Active_Eependents  field  in  the  G_AS7  is  decremented. 

The  pseudo-code  for  DEACTIVATE  PP.OCSDURE  is 
presented  in  figure  2f.  The  parameters  tnat  are  passed  to 
the  memory  manager  are  the  DBRj*  of  the  signalling  process, 
and  the  index  into  the  G_AST  for  the  segment  to  be 
deactivated.  The  procedure  first  updates  the  L_AST,  and  then 
removes  the  entry  if  no  local  process  holds  the  segment 
active.  The  G_AST  is  then  updated,  and  its  mentor  segment  is 
checked  (if  the  deactivated  segment  was  a  leaf),  to 
determine  if  it  can  be  removed.  If  no  processes  currently 
hold  the  segment  active,  and  it  has  no  active  dependents, 
the  segment  is  removed  from  the  G^AST. 

5.  Swan  a  Segment  In 

SWAP_IN  is  invoked  when  a  user  desires  to  swap  a 
segment  into  main  memory  (global  or  local)  from  secondary 
storage.  A  segment  is  swapped  into  main  (memory  by  obtaining 
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DEACTIVATE  PROCEDURE  (DBR  #  BITS,  PAR  INDEX  WORD ) 
RETURNS  (SUCCESS  CODE  “BYTE) 

LOCAL  INDEX  WORD 
ENTRY 

!  Check  if  segment  is  in  core  ! 

IF  G_AST  [INDEX]  .N0_ACTIVS_IN_M3M0RY  O  0  THEN 

!  Check  MMU  image  to  determine  if  in  local  memory  ! 
IF  IN  LOCAL  UFMORY  THEN 

SUCCESS  CODE  :=  OUT  (DPR  #,  INDEX) 

FI 

FI 

!  Remove  process  segment  no  entry  in  L  AST  ! 

L  AST [L  INDEX]  .SEGMENT~NO/ACCSSS  AUTHCDBR  #]  *  t 
ClTECK  IF  ACTIVE  IN  L  AST  (L  AST  INDEX^ 

IF  NOT  ACTIVE  IN  I  AST  THEN  " 

L  AST [L  INDEXj. MEMORY  ADDR  t=  AVAILABLE 
FI 

!  Check  if  deleted  segment  was  a  leaf  ! 

IF  G  AST [INDEX]. G  ASTE  #  PAR  <>  0  THEN 

G_AST  [PAR^INDEX]  ,NO_DEPENDENTS_ACTIVE  ~s  1 
!  Determine  if  parent  can”be  removed”! 

CHECK  FOR  REMOVAL  (PAR  INDEX) 

FI 

!  Determine  if  deactivated  segment  can  be  removed  ! 

CHECK  FOR  REMOVAL  (INDEX) 

SUCCESS  CODE  =  SEG  DEACTIVATED 
END  DEACTIVATE 


Figure  2£.  reactivate  Pseudo-code. 
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the  secondary  storage  location  of  its  page  table  from  the 
G_AST,  allocating  the  required  amount  of  main  memory,  and 
reading  the  segment  into  the  allocated  main  memory.  The 
segment  must  be  active  before  it  can  be  swapped  into  core, 
and  the  required  main  memory  space  must  be  available.  Three 
conditions  can  be  encountered  during  the  invocation  of 

SVAP_IN.  The  segment  can  already  be  located  in  global 

/ 

memory,  the  segment  can  already  be  located  in  one  or  more 
local  memories,  or  the  segment  may  only  reside  in  secondary 
storage. 

If  the  segment  is  not  in  local  or  global  memory, 
local  memory  is  allocated,  the  segment  is  read  into  the 
allocated  memory,  and  the  appropriate  entries  are  made  in 
the  WIT  image,  the  l_AST  and  the  G_AST .  If  the  segment  is 
already  in  global  memory,  it  can  be  assumed  that  the  segment 
is  shared  and  writable.  In  this  case  the  only  required 
actions  are  to  update  the  G_AST  and  I_/ST.  The 
Mo_Acti ve_In ..Memory  field  of  the  G_AST  entry  is  incremented, 
and  the  MM'J  image  is  updated  to  reflect  the  svapped  in 
segment's  core  address  and  attributes. 

If  the  segment  already  resides  in  ore  or  more  local 
memories,  it  must  be  determined  if  the  segment  is  "shared" 
and  "writable".  A  segment  is  "shared"  if  it  exists  ir.  more 
than  one  local  memory.  A  segment  is  "writable"  if  one 
process  has  write  access  to  that  segment.  If  the  segment  is 
not  shared  or  not  writable  and  in  local  memory,  the 
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appropriate  entries  are  updated  in  the  MM’J  image,  the  I_AST , 
and  the  G_AST.  If  the  segment  does  not  reside  in  local 
memory,  the  required  amount  of  local  memory  is  allocated, 
the  segment  is  read  into  the  allocated  memory,  and  the 
appropriate  entries  are  made  in  the  MMU  image,  the  L_AST, 
and  the  G_AST. 

If  the  segment  is  shared,  writable,  and  in  local 
memory,  the  segment  must  he  moved  to  global  memory.  If  the 
segment  is  not  in  the  memory  manager's  local  memory,  it 
signals  another  memory  manager  to  move  the  segment  to  global 
memory.  After  the  segment  is  moved  to  global  memory,  the 
memory  manager  signals  all  of  the  connected  memory  manager's 
to  update  their  L_AST  and  MMP  data  bases.  When  all  local 
data  bases  are  current,  the  memory  manager  updates  the  G_AST 
and  returns  a  success  code  of  seg_activated. 

The  pseudo-code  for  SWA?_IN  PROCEDURE  is  presented 
in  figure  21.  The  arguments  passed  to  SWAP_I N  are  the 
G_AST_INDEX  of  the  segment  to  be  moved  in,  the  process' 
DBKJ*,  and  the  access  authorized.  SWAP_IN  will  convert  the 
segment  size  from  bytes  to  blocks,  and  verify  that  the 
process'  core  will  not  be  exceeded.  If  the  virtual  core  will 
be  exceeded,  a  success  code  of  "core_space_exceeded"  will  be 
returned.  If  write  access  is  permitted,  the  writable  tit  is 
set.  Checks  are  then  performed  to  determine  the  segment's 
storage  location  (local  or  global),  and  the  appropriate 
action  is  taken. 
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WAP  IN  PROCEDURE  ( INDEX  WORD,  D5R  #  BYTE, 

ACCESS  AUTH  BITE^  ~ 

RETURNS  (SUCCESS  CODE  BYTE) 

IOCAI  I  INDEX  WORD,  DDKS  WORD 
ENTRY 

BLKS  :=  CALCULATE  NO.  OP  BLKS  (G  AST [INDEX] . SIZE) 
SUCCESS  CODE  :=  CHECK  MAX  LINEAR  CORE  (BLKS ) 

IE  SUCCESS  CODE  =  VIRTUAL  LINEAP  CORE  PULL  THEN 
RETURN 
FI 

G  AST [INDEX] .NO  SEGMENTS  IN  MEMORY  +■  1 

IF  ACCESS  AUTK  =  WRITE"  THEN 

G  AST  [INDEX] .FLAG  BITS  :=  WRITABLE  BIT  SET 
FI 

!  Determine  if  segment  can  tie  put  in  local  memory  ! 

IF  G  AST  [INDEX] .FLAG  BITS  AND  WRITABLE  MASK  =  0 
ORIF"  G_AST [INDEX] .NO^ACTIVF^IN^MEMORT  <»  1  THFN 
!  Determine  if  already  in  local  memory  ! 

CHECK  LOCAI  MEMORY  (L  AST  INDEX) 

IF  n5t  IN  LOCAL  MEMORY  THEN 
ALLOCATE  LOCAL  MEMORY  (BLKS) 

READ  SEGMENT  TPAGE  TABLE  LOG,  BASE  ADDR) 

I  AST [L  INDEX]  i  =  BAS?  AD?P. 

n 

ELSE 

IF  NOT  IN  GLOBAL  MEMORY  THEN 
U?DATE"MMU 
UPDATE"!.  AST 
RETURN"  " 

ELSE 

'^ALLOCATE  GLOBAL  MEMORY  (BLXS) 

IF  IN  L0CAL  MEMORY  THEN 

*OVE  TO  GLOBAL  (L  INDEX,  BASE  ADDR,  SIZE) 

ELSE 

SIGNAL  OTHER  MEMORY  MANAGERS ( INDEX .BASF  ADDR' 
FI 

f: 

FI 

UPDATE  VMU  IMAGE  (D5R  *,SEG  #,BASE  ADDR , ACCESS , BLKS ) 
UPPATE”L  AST  ACCESS  (L  INDEX .ACCESS, DBR  a) 

SUCCESS  COrF  :=  SWAPPE?  IN 

md  swap“:n 


Figure  21.  Swat*  In  Pseudo-code 


6.  Swap  a  Segment  Out 


SWA?_CUT  is  invoked  when  a  user  desires  to  move  a 
segment  cut  of  core.  A  segment  is  swapped  out  of  core  by 
obtaining  its  secondary  storage  location,  writing  the 
segment  to  that  location  (if  required),  and  deallocating  the 
main  memory  used.  The  decision  to  write  the  segment  is 
determined  by  the  G_AST  written  bit.  This  bit  is  set 
whenever  the  segment  has  been  modified.  The  segment  to  be 
swapped  out  can  be  in  one  of  two  states:  the  segment  can  be 
in  local  memory,  or  the  segment  can  be  in  global  memory. 

If  one  process  has  the  segment  in  local  memory  and 
the  written  bit  is  set,  the  segment  is  written  into 
secondary  storage  and  the  local  memory  is  deallocated.  If 
the  written  bit  is  not  set,  the  local  memory  need  only  be 
deallocated.  If  more  than  one  process  has  the  segment  in  the 
same  local  memory,  the  segment  remains  in  core.  The 
appropriate  image  is  updated  to  reflect  the  segments 
deletion  and  the  G_AST  No_Act  ive_Ir._Meme  ry  fi*ld  is 
decremented. 

All  segments  in  global  memory  are  shared  and 
writable.  If  a  process  requests  the  segment  to  be  swapped 
out,  the  segment  remains  in  memory.  The  image  is  updated 
to  reflect  the  segment's  deletion,  and  the  G_AST 
No_Active_In_Hemory  field  is  decremented.  If  the 
No_Active_In_venory  indicates  that  one  process  has  the 
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segment  in  core,  its  memory  manager  is  signalled  to  move  the 
segment  to  local  memory. 

The  pseudo-code  for  SWAF_0UT  PROCEDURE  is  presented 
ir.  figure  22.  The  arguments  passed  to  SWAP_0TJT  are  the  B3E_# 
of  the  signalling  process,  and  the  C-_AST_INISX  of  the 
segment  to  he  removed.  Tae  return  parameter  is  a  success 
code.  SVA?_0UT  removes  the  segment  from  the  process's 
virtual  core,  deletes  the  segment  from  its  MMU  image,  and 
decrements  the  No_Active_In J*!emory  field.  If  the  segment  can 
he  removed  from  memory,  it  is  determined  which  memory  can  he 
deallocated.  If  the  segment  has  been  modified,  it  is  written 
hack  to  secondary  storage  and  the  appropriate  memory 
deallocated.  If  the  segment  has  not  been  modified,  the 
appropriate  memory  is  deallocated.  If  after  the  deletion  one 
process  has  the  segment  in  global  memory,  its  memory  manager 
need  only  he  signalled  to  move  the  segment  to  local  memory. 
When  S’.WAF_0VJT  successfully  completes,  it  returns  a  success 
code  of  "swapped  out". 

7 .  Deactivate  All  Segments 

DEACTIVATE_ALL  is  invoked  when  it  becomes  necessary 
to  remove  a  segment  from  every  process'  address  space.  Each 
process  is  checked  to  determine  if  the  segment  is  active.  If 
a  process  has  the  segment  active,  it  is  deactivated  from  its 
address  space.  The  pseudo  code  for  Peactivate_all  is 
ill  isti'-ited  in  figure  23.  The  parameters  passed  to 
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SWAP  OUT  PFOC STORE  (DIR  *  BITE,  INDEX  WORD) 

RETURNS  (SUCCESS  COP!  BITE) 

ENTRY 

SIRS  :=  G  AST  [INDEX] .SIZE  /  3LK  SIZE 
FREE  PROCESS  LINEAR  CORE  ( BLKS )” 

DELETE  MKT  ENTRY  (DIF.  #,  SEG  #) 

G_AST [INDEX] .NO_SEGMSNTS_IN_MEMORY  -=  1 

!  Determine  if  segment  has~beer.  written  into  ! 

IF  MMU_IMAGB[DBR_#]  .SDF.[SSGjO  .ATTRIBUTES*WRITTFN  THEN 
I  If  segment  has  beer,  written  into,  update  G  AST  ! 

G  AST [INDEX] .FLAG  BITS  :*  WRITTEN 
FI 

f  Determine  if  segment  is  in  global  memory  ! 

IF  G  AS? [INDEX] .GIOBAL  ADDR  O  NULL  THEN 

If  G  AST[INDFX] ,n5  SEGMENTS  IN  MEMORY  =  P 
ANDIF“  G  AST[INDEX]7n.AG  BITS  *"VRITTEN  THEN 
WRITE  SEG  (PAGE  TABLE  LOC ,  MEMORY  ADDR) 

FREE  L0CAl_BIT  MAP  (MEMORY  ADDR, BLKS T 
ELSE  ” 

”  "  ’’if  G  AST  [INDEX]  .NO  ACTIVE  IN  MEMORY  =  P-  THEN 
FREE  IOCAL  BIT~MAP  (MEMORT  ADDR.ILKS^ 

FI 

FI 

ELSE  !  If  not  in  global  memory  ! 

IF  G  ASTflNDEX]  .NO  ACTIVE  IN  MEMORY  =  2 
AND IF  G  AST [INDEX] 7FLAG  BITS"»  WRITTEN  THEN 
WPITE  SEG  (PAGE  TABlE  LOC,  GLOBAL  AIDE ) 

FREE  GLOBAL  BIT  MAP  (GLOBAL  ADDR,  BLKS) 

ELSE 

IF  G  ASTflNDEX] .NO  ACTIVE  IN  MEMORY  =  t  THEN 
FREE  GLOBAL  BIT  MAP  (GLOBAL  ADDR,  BLKS) 

FI 

FI 

FI 

SUCCESS  CODE  :=  SWAPPED  OUT 
END  SWA?"OUT 


Figure  22.  Svap_Out  Pseudo-code. 
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DEACTIVATE  AIL  PROCEDURE  (INDEX  MED,  L  INDEX  MED) 
RETURNS  (SUCCESS  CODE  LTTE) 

ENTRT 

LOCAL  I  BYTE 
I  :*  C 
DO 

IF  I  *  MAX  DBR  #  THEN 
EXIT 
FI 

IF  L  A.STCL  INDEX)  .SEGMENT  NO/ACCSSS  AUTH  [ I ) 
"  O  Z?F0  THEN 

SUCCESS  CODE  :«  DEACTIVATE  (I,  INDEX) 

IF  SUCCESS  CODE  O  SEG  DEACTIVATED  THEN 
RETURN  ~ 

FI 

FI 

I  +*  1 
OD 

SUCCESS  CODE  5=  VALID 
END  DEACTIVATE"^! 


Figure  23.  Deactivate  All  Pseudo-code. 
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Deactivate_all  are  the  deactivated  segment's  G_AST  index  and 
the  L_AST  index.  The  I_AST  is  searched  by  D£R_#  to  determine 
which  process  has  the  segment  active.  If  the  check  reveals 
that  the  segment  is  active,  it  is  deactivated  by  calling 
Deactivate.  If  the  segment  was  successfully  deactivated  from 
all  processes,  a  success_code  of  valid  is  returned. 

8.  Move  a  Segment  to  Global  Memory 

M0VF_T0_0L0J At  is  invoked  when  it  becomes  necessary 
to  move  a  segment  from  local  to  global  memory.  If  a  segment 
resides  in  one  or  more  local  memories,  and  a  process  with 
write  access  swaps  that  segment  into  core,  or  if  a  segment 
resides  in  in  local  memory  (with  write  access)  and  another 
process  with  read  access  requests  the  segment  swapped  in, 
the  segment  is  moved  from  a  local  to  global  memory  to  avoid 
a  secondary  storage  access.  If  the  segment  resides  in  the 
running  memory  manager's  local  memory,  it  will  affect  the 
segment  transfer,  otherwise  it  will  signal  another  remcry 
manager  of  a  connected  processor  to  affect  the  transfer. 
Figure  24  illistrates  the  pseudo-code  for  M0VF-_T0_GI03AI . 
Once  the  segment  has  been  moved  to  global  memory,  the 
signalled  memory  manager  will  update  the  MM’J  images  for  all 
connected  processes,  and  deallocate  the  freed  local  menory. 
A  success  code  of  completed  will  be  returned  to  the 
signalling  memory  manager.  The  parameters  passed  to  the 
memory  manager  are  the  segment's  L_AST  index  ,  the  global 
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MOVE  TO  GLOBAL  PROCEDURE  (L  INDEX  tfORD,  GLOBAL  AD  DP.  WORD, 

SIZE  WOPD ) 

RETURNS  (SUCCESS  CODE  BYTE) 

ENTRY 

!  !^ove  segment  from  local  memory  to  global  memory  ! 

DO  MEMORY  WOVE  (MEMORY  ADD?.,  GLOBAL  ADDR) 

LjtSTflNDSX] .MSMOSI.ADBR  :  =  AVAILABLE 
!  Update  the  MMlT  image  to  reflect  new  address  ! 

DO  FOR  AIL  DBR'S 

IF  L  ASTTI  INDEX] .SEGMENT  NO/ACCSSS  AUTH  <>  e  AND IF 
MwtJ  IMAGE [SB?  #].SDR[SEG  #]  .ATTRIB’JTES*IN  LOCAL  THEN 
MMU  IMAGE [DBR  #] .$DR[SEG  #] .BASE  ADD?:=GLOBAL  ADDR 
FI 

or 

SUCCESS  CODE  j*  VALID 
END  MOVE  TO'GLOBAL 

•r  •• 


Figure  24.  Move  To  Global  Pseudo-code . 
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memory  address  of  the  move,  and  the  size  of  the  segment. 
This  information  is  passed  because  the  G_AST  is  locked 
during  this  request. 

9.  Move  a  Segment  to  local  Memory 

MOVSJTO^IOCAL  is  invoked  when  it  becomes  necessary 
to  move  a  segment  from  global  to  local  memory.  This  occurs 
when  one  of  two  processes  which  hold  a  segment,  in  global 
memory  swaps  the  segment  out.  The  segment  is  moved  from 
global  memory  to  the  local  memory  of  the  remaining  process. 
Figure  25  illustrates  the  pseudo-code  for  MOVE^TO^IOCAL.  The 
parameters  passed  to  the  memory  manager  are  the  segment's 
L_AST  index,  the  global  address  of  the  segment,  and  the  size 
of  the  ;egment.  The  return  parameter  is  a  success  code.  The 
MMU  images  of  the  signalled  process  are  updated  after  the 
move  has  been  made,  and  the  global  memory  is  deallocated. 

10 .  Update  the  MMU  Image 

UPDATE  is  invoked  following  a  MOVSJTOJJIOBAL 
operation.  After  a  segment  has  been  moved  from  local  memory 
to  global  memory,  it  is  necessary  to  signal  the  memory 
managers  of  all  connected  processors  to  update  their  MMU 
images  and  L_AST  with  the  current  loca*ion  of  the  segment. 
They  must  also  deallocate  the  moved  segment's  local  memory. 
Figure  26  illustrates  the  pseudo-code  of  UPDATE.  The 
parameters  passed  to  the  memory  manager  are  the  segment's 


MOTS.TO.IOOAI  PSOCEC’JSS  (l  IWEX^WOBB,  SIOBAL.AMP  ’IOSB, 

RETURNS  (SUCCESS.CODE  B7T3) 

ENTRT 

Ssl  ADDRESS  (xEAlfOCATE_LOCAL^ORY  (BUS) 

1  SSa!TrfSf?1(c&ii.«w'  Srimp-ss,  SIZE) 

I  AST [E^INDEX] .MEKORT_ADDR  i*  BASL_ ADDRESS 

D^IF?IA5’Tri"’lNDE7)  .SEGMENT  NO/ACCESS  AUTR  <>  t pn'ILw 

,^il5SS?5»Sii5“5l“fSlif!Sa!ZlS;SiSSI!5»i.»« 

II 

OD 

SUCCESS  CODE  :  =  VALID 
END  M0VE_T5_L0CAI 


figure  25.  Move  To  Local  Pseudo-code, 
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TTPDATE  PROCEDURE  (I  INDEX  WORD,  GLOBAL  ADDR  WORD, 

SIZE  WORD) 

RETURNS  (SUCCESS  CODE  BYTE) 

ENTRY 

DO  FOR  All  DBR  'S 

IF  1‘ASTTL  INDEX] .SEGMENT  NO/ACCESS  AUTH  <>  0  ANDIF 
MMU  IMAGE  [PER  #]  .SDR  [SEC-  #]”.  ATTRIBUTES  =  IN  IOCAl  THEN 
MMTJ  IMAGECDBR  #].SDRlS2G  #]  .BASE  ADDR  7= 

GLOBAL  ADDK 
FI 
OD 

BLKS  :=  SIZE  /  BLK  SIZE 

FREE  LOCAL  BIT  MAP~(M?MORl  ADDR, BLKS) 

L  AST [L  INDEX] TmEMORT  ADDR  :*  ACTIVE 
SflCCESS~COPE  :*  VALID” 

END  UPDATE  ” 


Figure  26.  Update  Pseudo-code. 
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L_AST  index,  the  new  global  address  for  the  segment,  and  the 
size  cf  the  segment.  The  return  parameter  is  a  success  code. 

E.  SUMMARY 

In  this  chapter  the  detailed  design  of  the  memory 
manager  process  has  been  presented.  The  purpose  of  the 
memory  manager  was  outlined,  followed  by  a  detailed 
discussion  of  the  memory  manager's  data  bases.  The  design 
presented  has  identified  ten  basic  functions  for  the  memory 
manager.  The  implementation  details  of  these  functions  are 
pre'-onted  in  Appendix  A.  The  success  codes  returned  by  the 
memory  manager  are  presented  in  figure  27. 

This  design  has  assumed  that  the  kernel  level 
inter-process  synchronization  primitives  will  be  Seltzer's 
signal  and  wait  primitives [15] .  This  fact  dominated  the 
design  decision  to  lock  the  5_AST  in  the  user's  process 
before  it  signals  the  memory  manager.  In  a  mul  l-processor 
environment,  the  possibility  of  a  deadly  embra-e  exists  if 
the  memory  manager  processes  lock  the  G_AST.  Should  follow 
or.  work  implement  eventcounts  and  sequencers  <*.s  kernel  level 
synchronization  primitives,  the  locking  of  the  0_AST  and 
remory  manager  synchronization  will  need  to  be  readdressed. 


SYSTEM  WIDE 

INVALID 
SWAPPED  IN 
SWAPPED~OUT 
SEG  ACTIVATED 
$EG~DEACTIVATED 
SEG~CRBATED 
SEG~DSLETED 
VIRTUAL  CORE_FULL 
DUPLICATE  SNTRT 
READ  ERROS 
WRITE  ERROR 
DP.IVE"NOT  PEADT 


MEMORY  MANAGER  LOCAL 

VALID 
INVALID 
FOUND 
NOT  FOUND 
IN  LOCAL  MEMORY 
NOT  IN  LOCAL  MEMORY 
!  +  DISK  ERRORS  ! 


KERNEL  LOCAL 

LEAF  SEGMENT  EXISTS 
NO  LEAF  EXISTS 
ALIAS  DOES  NOT  EXIST 
NO  CHILD  T5  DELETE 
G  ASTJFULL 
l"ast  FULL 
LOCAL~MEMORY  FULL 
GLOBAL  MSMORYJFULL 
SECONDARY  STORAGE  FULI 


Figure  27 


Success  Codes 


IV.  STATUS  OF  RESEARCH 


A.  CONCLUSIONS 

The  memory  manager  design  utilized  state  of  the  art 
software  techniques  and  hardware  devices.  The  design  was 
developed  based  upon  ZILCG'S  ZSetl  sixteen  bit  segmented 
microprocessor  used  in  conjunction  with  the  Z8£lfc  Memory 
Management  Unit [12].  A  microprocessor  which  supports 
segmentation  is  required  to  provide  access  control  of  the 
stored  data.  The  actual  implementation  of  the  selected 
thread  was  conducted  upon  the  Z8002  non-segmented 
microprocessor  without  the  Z6210  m.MU. 

While  information  security  requires  that  the 
microprocessor  support  segmentation,  the  memory  manager  was 
developed  to  be  configuration  independent.  The  design  will 
support  a  multi-processor  environment,  <jtd  can  be  easily 
implemented  upon  any  microprocessor  or  secondary  storage 
device.  The  loop  free  modular  design  facilitates  any 
required  expansion  or  modification. 

Global  bus  contention  is  minimized  by  the  memory 
manager.  Segments  are  stored  in  global  memory  only  if  they 
are  shared  and  writable.  -Secondary  storage  is  accessed  only 
if  the  segment  does  not  currently  reside  in  global  memory  or 
some  local  memory.  The  controlled  sharing  of  segments 
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optimizes  main  memory  usage. 

The  storage  of  the  alias  tables  in  secondary  storage 
supports  the  recreation  of  user  file  hierarchies  following  a 
system  crash.  The  aliasing  scheme  used  to  address  segments 
supports  system  security  by  not  allowing  the  segment's 
memory  location  or  unique  identification  to  leave  the  memory 
manager. 

The  design  of  the  distributed  kernel  was  clarified  by 
assigning  the  MMU  image  management  to  the  memory  manager. 
The  transfer  of  responsibility  for  memory  allocation  and 
deallocation  from  the  supervisor  to  the  memory  manager 
provides  support  for  dynamic  memory  management. 

In  conclusion,  the  memory  manager  process  will  securely 
manage  segments  in  a  multi-processor  environment.  The 
process  is  efficient,  and  is  configuration  independent.  The 
primitives  provided  by  the  memory  manager  will  support  the 
construction  of  any  desired  supervisor/user  process  built 
upon  the  kernel. 

B.  FOLLOW  ON  WOHK 

There  are  several  possible  areas  in  the  SASS  design  that 
can  be  looked  into  for  continued  research.  The  complete 
implementation  of  the  memory  manager  design  (refine  and 
optimize  the  current  PLZ/SIS  code)  is  one  possibility.  Other 
possibilities  include  the  implementation  of  dynamic  memory 
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management,  and  modifying  the  interfare  of  the  memory 
manager  with  the  distributed  kernel  using  eventcounts  and 
sequencers  for  inter-process  communication. 

The  implementation  of  the  supervisor  has  not  been 
addressed  to  date.  Areas  of  research  include  the 
implmentation  of  the  file  manager  and  input/output 
processes,  and  the  complete  design  and  implementation  of  the 
user-host  protocols.  The  implementation  of  the  gatekeeper, 
and  system  initialization  are  other  possible  research  areas. 
Dynamic  process  creation  and  deletion,  and  the  introduction 
of  multi-level  hosts  could  also  prove  interesting. 
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APPENDIX  a  -  PIZ/STS  SOURCE  LISTINGS 


MEMORY  M A N AG ?F. _Pt  Z  _S  Y  S  MODULE 


*  «  «  «  VERS.  1.0  #  *  *  * 


! 


CONSTANT 


FALSE 

TRUE 

AVAILABLE 

ACTIVE 

ZERO 

NULL 

NULL  PAGE 


!  SUCCESS  CODES  ! 
INVALID 
VALID 
FOUND 
NOT  FOUND 
SWAPPED  IN 
SWA?PSD**CUT 
SEG  ACTIVATED 

seg“dsactivated 

ssg"'crsatsd 

seg’deletfd 

LEAF  SEGMENT  EXISTS 
NO  LEAF  EXISTS 
G  AST  FULL 
L~AST  FULL 
ifl  LOCAL  MEMORY 
NOT  IN  LOCAL J'FMQPY 
IOCAI  MEMORY  FULL 
GLOBAL  MEMORY  FULL 
VIRTUAL  COR?_FUII 
DUPLICATE  FNTRT 
NO  CFIID  TO  DEISTS 


*  aTTPIBUT?  masks 
read  MASK 
WRITE  M.»e.' 
CHANGED  MASK 
IN  MEMORY  MAS T. 
CLEARED 


=  0 

=  e  !  AST  ENTRY  AVAIL.  ! 

*  1  !  AST  ENTFY  ACTIVE  ! 
=  0 

*  %ee e e 

*  0 


*  e 

=  l 

*  2 
»  3 
s  4 

*  5 
s  6 

*  7 

»  e 

=  9 
=  10 
=  11 

*  12 
=  1? 

*  14 
=  15 
=  16 
=  17 

*  1? 
=  19 
*  20 


=  % (2)11111110 
=  2(2)00000001 
=  % ( 2 }010Z0020 
=  2(2)001*00100 
=  ?  !  CLEAR  ATTRIBUTES  ’ 


l  AUTHOR  I ZSD_ACCESS 


WHITT 

EXECUTE 


! 


! 

TYPE 


1 

2 


G  A ST  FLAG  BITS  MASKS 
“  WRITABLE  MASK 
WHITTEN  MASK 


%(2)ee0?m? 

%(2)p£e££ice 


DESIGN  PA?.  AM  STEPS 


BIX  SIZE 
MAX"? AGE  SIZE 

matTmsg  size 

G  MEM  SIZE 

i"mem"sizs 

NO  OF"PHOCESSORS 

_  !  MAX  NUMBER  0! 

MAX  DPR  NO 


a  2£6 

*  BIK  SIZE  /  2 
=  16“ 

*  ?  !  SIZEOF  GIOEAI  MEM  ! 
=  ?  ! SIZEOF  ICCAI.  MEMORY’ 

*  1 

DBH  #'S  ! 

s  4 


!  MAX  ENTRIES 
G  AST  I IM IT 

!  MAT  ENTRIES 
I  AST  LIMIT 

“  "  !  SIZE  OF  ALIAS 

MAX  ENTRY  NO 

OF  SEGMENTS 


IN  G  AST 
*  160 
IN  L  AST 
=  170 
TABLE 
=  32 

PER  PROCESS 


NO  SEG  LESC  REG  :  =  64 

FIRST  POSS  FREE  BIOCK  :=  1 

PROCESSOR.  IOCAl“BATA"  ! 

PROCESSOR  ID  0 


ADDRESS  VORT 


ALIAS  HEADER  PECOP.D  [  SEG  PAGE  TABLE  LOC  WORD 

parIaliaJ.tabl2.loc  WCKD  ] 


ALIAS 


FICOFD 


UNIQUE  ID  ICNG 

WCPT 

SIZE  " 

WORD 

CLASS 

WORD 

PAGF  TABLE  LOC 

VC  FT 

ALIAS  TABLE  LOC 

WORD  ] 

SEG  DESC  REG  RECORD 


f  BASE  ADDR 
LIMIT 

ATTRIBUTES 


ADDRESS 
BYTE 
BYTE  ] 


MMU  RECORD  [  SDR  ARRAY [NO  SEG  DESC  ?*G 

SEG”rESC  FEC-"] 

31 KS  USED  'iOPf 

MAXJ- IKS  WORD  :=  ????  J 

G  AST  REC  FECOFD  [  UNIQUE  ID1  LONG  WORD 

GLOBAL” ADD?  ADDRESS 

PROCESSORS  L  ASTE  NO  ARRAY 
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[NO  Or  PROCESSORS 

WORD] 

FLAG  BITS 

RITE 

G  ASTE  NO  FAR 

WORD 

NO  ACTIVE  IN  MEMOFY 

WORD 

no”active  DEPENDENTS 

WORD 

SI^El 

WORD 

RAGE  TA2LF  LOCI 

WORD 

ALIAS  TAELE  LOCI 

WORD 

SEQUENCER 

WORD 

INSTANCE1 

WCRT 

INSTANCB2 

WORD  ] 

I  AST  REC  RECORD  [  MEMORY  ADDR  ADDRESS 

SEGMENT  NO  ACCESS  ATTH 

ARRAY”  [MAX_DRR_NO  BVTE]  j 

HANDLE  RECORD  [  UMCUE  ID2  LONG  WORD 

H_INDSX  ’  WORD  ] 


*  A 

*  VAPIA51S  DECLARATIONS  * 

)S  >|t 

AA^jjtAA AAA AAAA  | 

^SECTION  G_DATA 

GLOBAL  G  AST  ARRAY  fO  AST  LIMIT  G  AST  RSC] 

GLOBAL^MEVJIT.KA?  ARRAYfG^MORY.SIZE/ie  WORD] 

^SECTION  I_DATA 

MMU  IMAGE  ARRAY  [MAX  DPR  NO  MMV] 

l  AST  ARRAY  [I  AST  IIMIT  I  AST  RECl 

ALIA?  TABLE  «SC0^r  [  HEADER  AIIAS”KEADSR 

All  AS  ENTRY  ARRAY 

[max  Entry  no  alias]  ] 

IOCAI  "EK  BIT  PA?  AR?.Ay  [L  vvk  SIZE/16  WO  31] 
DISE  Sit  Mi?  EUFF  ARRAY  r????  ~  BYTE] 

?age"tail?  BUFFER  ARFAY  [ELK  Siz?  eytf] 


EXTERNAI 


*  * 

*  The  following  procedures  are  coded  in  PIZ/ASM  and  are  * 

*  contained  in  a  separate  PIZ/ASM  rodule. 

jjt 

>!<  $$$$&>;*$>!<$$$*!(>!*>•<$$  i;<  >>  ^ »;« $  >;*  #  *:  *t  #  >;»  >;:#»;<#  *•.  &  >;<  #  #  .;•  >;«  j 


READ  PAC- 3  PROCEDnRS  (DISK  IOC  WORD 
RETURN'S  (  SUCCESS  CODS  BYTE  ) 


MEMORY  ADTr.  ADDRESS' 


READJEGMENT  PROCEDURE  (PAGE_TA31E_LOC 
RETURNS  (  SUCCESS  CODE  BYTE  ) 


WORD  ,  MEMORY  ABDR 

•.miss) 


WRITE  PAGE  PROCEDURE  (DISK  IOC  WORD 
r2?U?.N?  (  SUCCESS  C0DE"BYT3  ) 


FROMJtDDR  ADDRESS ' 


WRITEJEGMENT  PROCEDURE  (PAG3_TABIE_I0C  WORD 
RETURNS  (  SUCCESS_CODE  BYTE  ) 


FROM  AD DR 
ADERFSS) 


READ  DISK  BIT  MAP  PROCEDURE 

“  P.ETUFNS  (  SUCCESS  CODE  BYTE  > 


WRITE  DISK  BIT  Mi?  PROCEDURE 

"RETURNS  T  SUCCESS.COPB  BYTE  ) 

c FARCE  DISK  BIT  MAF  PROCEDURE  (START  ?P.CP  IOC  WOF.D) 
RETURNS  (  SUCCZSS.CODE  BYTE,  BIK_IOC  WORT  ) 

CIEA8.ri5K.PIT.MA?  PROCEDURE  (  BLX_LOC  WORD  ) 

??.EE_GIOBAI_BIT.MAP  PROCEDURE  (ADD?  ADDRESS,  3US  WORD) 

FFEE.ICCAI.2IT.MAP  PROCEDURE  (ADD?  ADDRESS,  BIKS  WORD 

AIIOC  IOCAI  *3M0?Y  PROCEDURE  (BIKS  WORD) 

RETURNS  7  S’TCCESS.COIE  BYTE  ,  BASS.ADDR  ADDRESS  ) 

AIIOC  GIOBAI  MEMORY  PROCEDURE  (BIKS  WORD) 

RETURNS" (  SUCCESS  CODE  BYTE,  BASE  A DDR  ADDRESS  ) 


GET  TJN 10  ID  PPOCSDURF 

“  PETUTJNS  (  ID  I0NG  WORD,  SUCCESS_CODE  BYTE  ) 

MEMORY_MOVE  PROCEDURE  (TO  ADDRESS,  FROM  ADDRESS,  SIZE  WORD) 

7ALIDATE  MSG  PROCEDMFF  (MSG  ARRAY  (MAX  MSG  SIZE  BYTE] ) 
RETURNS  (  FUNCTION  BYTE,  ARGUMENTS  ARRAY  "(6  WORD]  ) 


1?? 


it  it 


VALIDATE  WAIT  MSG  PROCEDURE  'MSG  AREA!  [MAX  MSG  SIZE  SITE] ) 
EET'PFI?  (  SUCCESS  BYTE  ) 


INTERNAL 

J  *>!«  #!)»!«  >!«  >!<>!«  >!«>!«♦  >!<>(<  *>!<  >!«>!«  >!<*>!« 


*!»  * 

*  The  READ_ALTAS_TABLE  Procedure  is  called  from  the  # 

*  Create_entry  procedure  and  Delete_entry  procedure.  * 

*  T:  e  orocedure  will  read  the  requested  alias  table  * 

*  from  secondary  storage  to  main  memory.  * 

*  # 


REAL  ALIAS  TABIE  PROCEDURE  (  ALIAS  DISK  LOC  WORD, 

MEMORY  Am  ADDRESS  ' 

RETURNS  (  SUCCESS  COLE  BYTE  ) 

ENTRY 

SUCCESS  CODE  J«  REAL  PAGE (ALIAS  DISK  LOC,  MEMORY  A DDR ' 
END  READ  ALIA?  TABIE 


» *  4  *  $  #  *  *  *  $  >!«  >!<  *  ft  #  %  A  >!«  >!«  >!*  4*  $  #  #  *>!«  $  *  #  $  *  >,V $  :)«  #  #  $  if  j}<  *  *  fc*  4  &  >fi 

*  * 

*  The  WRITE_AIIAS_TA.BI2  Procedure  is  called  from  the  # 

*  Create jentry  and  Delete^entry  procedures.  Tve  pro-  * 

*  cedure  will  write  the  appropriate  alias  table  from  * 

*  main  memory  to  secondary  storage.  * 

*  * 


WRITE  ALIAS  TABLE  PROCEDURE  (  ALIAS  DISK  LOC  WORD, 

MEMORY  ADD?  ADDRESS  '• 

RETURNS  (  SUCCESS  CODE  BYTE  ) 

ENTRY 

SUCCESS  COD”  :=  WRITE  PAGZ(AIIAS  DISK  LOC,  MEMORY  ADD?. ) 
END  W-ITS  ALIAS  TABIE 


ies 


t  AAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAxAAAAAAAAAAAAAAAAAAAAAA 

A  j{t 

*  The  SSARCH_ALIAS  TABLE  Procedure  is  called  frotr  the  * 

*  Create_alias_table  procedure.  The  procedure  will  step  * 

*  through  the  alias  table  until  it  matches  the  passed  * 

*  unique_id  with  a  table  entry,  or  the  table  has  been  * 

*  exhausted.  The  procedure  returns  a  success  code  of  * 

*  either  found  or  not_found,  and  the  appropriate  index  * 

*  into  the  alias  table.  ’  *  * 

A  A 

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa J 

S SAUCE  ALIAS  TABLE  FROCEDURE  (  UNIQUE  ID  LONG  WORD  ) 

P  "TURNS-  (  SUCCESS  CODE  3YTE ,  INDEX  BVTE  ) 

ENTRY 

INDEX  : =  p 

SUCCESS  CODS  :=  NOT  FOUND 
DO 

IF  INDEX  >  PAX  ENTRY  NO  THIN  EXIT 
FI  " 

IF  ALIAS  TABLE, ALIAS  ENTRY  [INDEX] .UNIQUE  ID  « 

UNIQUE  II  THEN 

SUCCESS  CODS  :*  FOUND 
EXIT 
FI 

INDEX  *■  1 
OD 

END  S FAR  CP  AIIAS  TABLE 


*  AAAAAAAA&AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAV 

A  A 

*  The  U?DATE_MMU_lMAOS  Procedure  Is  called  from  the  In  * 

*  procedure.  The  procedure  win  update  the  MMU  image  of  <* 

*  the  appropriate  process  with  the  memory  location,  * 

*  limit,  and  access  authorization  for  the  passed  segment  * 

*  number.  * 

A  A 

AAAAAAAAAAAA AAAAAA AAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAA AAAAA I 

UPDATE  MPiU  IMAGE  PROCEDURE  (DIR  NO  BYTE,  SEGMENT  NO  BYT?, 

ADDP.  ADDRESS,  ACCESS  BYT2 ,  LIMIT  r^TE  ) 
LOCAL  ATTR  BYTE 
ENTRY 

MMU  IMAGE [DB^  NO] .SDR  [SEGMENT  NO] .BASS  AD DR  :=  A DDR 
MMU'lPAGE[DBR"NO] .SDR[SEGMSNT"NO] .LIMIT  :  =  LIMIT 
ATTR  :=  IPAGE[DBR  NO] .SDRlSEGMENT  NO] .ATTRIBUTES 
!  CISAR  PREVIOUS  ACCESS  ! 

I?  ACCESS  =  READ  OKI?  ACCESS  =  WRITE  THEN 
ATT?  :=  ATTR  AND  2(2) 111111 ID 


ieg 


I 

I 


ELSE  !  EXECUTE  ONLY  ACCESS 

ATT?  :=  ATTR  AND  *{2)11X10111 
FI 

Mf*UjPAGE[m  JIO]  .SDHCSEGMENT.NO] 
END  UF DATE JWU_ IMAGE 


ATTRIBUTES  :  = 
ATT?.  0*  ACCESS 


j  *  $  $  ft#  $>}<>(«  #  jfc  »[t#  »;<  $$$$  ££  #  »|«  ##  #  ##  ##  x’oic 


#  % 

*  The  DEIETE  JMMU.ENTRY  Procedure  is  called  from  the  Out  * 

*  procedure. "The "procedure  will  null  out  the  mmu  image  # 

*  of  the  appropriate  process  for  the  passed  segment  * 

*  number.  * 

if  if 


#  j|t  #  #  i*«  :',t  $  V,«  $  $  t,1,  ft#  #  i|;  vf  j;t  $  j;,  )Jt  #  )|t  »;<>:($  >;<  i,t  !|!  &  *t  »;«  i|i  *  ill  >;r  !;:  i,;  >;i  $  $  $  #  1|!  j;i  )J|  if  v  *  III  { 

DELETE  mmtt  TNTRY  PROCEDURE  (  DER  NG  BYTE,  SEGMENT  NO  BYTF  > 
ENT?T  ~ 

MMU  IMAGE fDBR  NO]  .SDH [SEGMENT  NO]  .BASE  ADD?  :=  NULL 
WMU~I MAGE  [DPR  NO]  .SDR [SEG"FNT~N0]  .LIMIT  :=  ZERO 
MMU_IMACZ  [D31t**N0]  .SDR [SEGMENTING]  .ATTRIBUTES  :  =  CLEARED 
END  DELETE  ENTRY 


I  *  #  *  #  ft  A  $  ftrt  *  $»; t  $  if.  $»!!,!«  #>!<#  $  A  *l”l« 

if  <t 

*  The  FIND_SECONrA?.Y_STORAGE  Procedure  is  called  from  * 

*  the  Alloc_sec_.s torage  procedure.  The  procedure  will  * 

*  search  the  secondary  storage  bit  map  to  find  a  cor-  * 

*  tiguous  storage  location  in  secondary  storage  for  the  * 

*  required  number  of  blocks  passed.  The  procedure  will  * 

*  return  a  success  '-ode  of  either  valid  or  invalid.  *' 

*  * 


FIND  SEC  STORAGE  PROCEDURE  {  BLKS  WORD  ) 

RETURNS  (SUCCESS  CCDE  BYTE, TABLE  APRAY  [BLK  SIZE  WORD]' 
I OCA I  INDEX  WORD 
I  WORE 

ENTRY 

SUCCESS  CODS  :=  *EAD  DISK  BIT  MAP 
IF  SUCCESS  CODE  O  VALID  THEN 
RETURN 
FI 

INDEX  :=  FIRST  POSS  FREE  BLK 
I  :=  ? 

DO 

SUCCESS  CODE,  INDEX  :=  SEARCH  DISK  BIT  MAP  (INDEX) 


IT  SUCCESS  CODS  <>  VALID  THEN 
TO 

CLEAR  DISK  BIT  MAP  (  TABLE  [I]  ) 
IT  I”*  P  ~  THEN  EXIT 
TI 

I  -=  1 

OD 

SUCCESS  COTT  :  =  SEC  STOP  FULL 
RETURN 
FI 

TABIE  ri]  *■  INDEX 
I  **  1 

IT  I  =  BLKS  THEN  EXIT 
TI 
OD 

SUCCESS  CODE  :=  VALID 
TNE  FIND  SEC  STORAGE 


it  <« 

*  The  AIIOC_ONE_PAGS  Procedure  is  called  from  the  Create  # 

*  alias_table  procedure.  The  procedure  will  fird  ore  * 

*  page  of  secondary  storage  for  the  creation  of  ar.  alias  * 

*  table.  This  procedure  will  return  a  success  code  of  * 

*  either  valid  or  invalid. 

* 


ALLCC  ONE  PAGF  PROCEDURE 

RETURNS  {  SUCCESS  CODE  BYTE,  PAGE  LOCATION  WORD  ) 
LOCAL  TABLE  ARRAYTBLK  SIZE  WORD] 

ENTRY 

’SUCCESS  CODE,  TABLE  :  =  FIND  SEC  STORAGE  (  1  ) 

IT  SUCCESS  CODE  <>  VALID  "TFSN 
RET’tFN 
TI 

FAGS  LOCATION:*  TABLELE] 

END  AILOC  ONE  PAGE 
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■>  * 


*  $ 

*  The  AII0C_$SC_ST0?.AG2  Procedure  is  called  from  the  * 

*  Create_er.try  procedure.  The  procedure  will  create  a  * 

*  pare  table  from  the  allocated  secondary  storage,  and  * 

*  write  this  page  to  secondary  storage.  This  procedure  # 

*  will  return  a  success  code  of  valid  or  invalid.  # 

*  # 

*#$#####»:«#  #>!<»!«  >!*>!«#>(<>!«>!«>!«  $#$>!«>!«>(«#>!«>!«>!«>!«  t 

AIIOC  SEC  STORAGE  PROCEDURE  (  ELKS  WORD  i 

RETURNS  (  PAGE  TAEIE  IOC  WORD ,  SUCCESS  CODE  BYTE  ) 
LOCAL  TAEIE  ARRAY  JBLK  SIZE  WORD] 

ENTRY 

SUCCESS  CODS,  TAEIE  :=  FIND  SEC  STORAGE  (  SIX'S  *  1  ) 

IE  SUCCESS  CODE  O  VAX  ID  THEN 
RETUFN" 

El 

PAGE  TABIE  LOC  :=  TAPIS  [0] 

I  :="! 

DO 

FAG?  TABIE  BUFFER  [i-lj  :=  TABIE  [I] 

IF  T  =  BISS  THEN  EXIT 
FI 

I  +=  1 

or 

DO 

IF  I  =  MAX  PAGE  SIZE  THEN 
EXIT 
FI 

PAGE  TABIE  BUFFER  [1-1]  :=  NUII  PAGE 

I  +«"i 

OD 

SUCCESS  CODS  :=  WRITS  PAGE  (  PAGE  TABLE  LOC, 

"H PAGE- TAB IE  SUFFER  > 

END  AIIOC  SEC  STORAGE 


iesje  »}t  $  jJs  >|s  £  if  #  #  #  *:*  #  $  sjt  #  >J<  *  $  $  $  £  %  $  ft  <s  #  tf  $  *  ❖  £  #  *  if  $  $  ft  if  #  $  £  >!t  iji  #  $  $  $  *  $  $  #  $ 

if 

The  CRSA?S_ALIAS_TABLE  Procedure  is  called  by  the  * 

Create_entry  procedure.  The  procedure  will  allocate  * 
secondary  storage  for  the  creation  of  an  alias  table  # 
and  update  the  mentor  segment's  alias  table  to  reflect  * 
the  created  alias  table's  secondary  storage  location.  * 
The  procedure  returns  a  success  code  of  either  valid  * 
or  inval  id  .  * 


CREATE  ALIAS  TABLE  PROCEDURE  (  PAR  INDEX  WORD  ) 
RETURN?  t  SUCCESS  CODE  BYTE  )~ 

LOCAL  PARENT  BYTE 

ALIAS  TABLE  LOC  WORD 
ENTPY“NC  BYTE 


END 


ENTRY 

SUCCESS  CODE  ,  ALIAS  TABLE  LOC  :=  ALLOC_ON'E  PAGE 
PARENT  7=  G  AST  [PAP.  INDEX] 7g  ASTE  NO  PAR 
SUCCESS  CODE  :=  READ  ALIAS  TABLE(G  AST[PA?EN?]. 

ALIAS"TABLE"LOCl,  BALIAS  TABLE  ) 

IF  SUCCESS  CODE  O  VALID  THEN 
PSTURM" 

FI 

SUCCESS  CODE,  ENTRY  NO  :*  SEARCH  ALIAS  TABLED 

G  A;’T  [PAR  INDEX]  TUNIOUF  IT1  ) 
IF  SUCCESS  CODE  =  NOT  FOUND  THEN 
RETURN 
FI 

ALIAS  JTABLS. ALIAS  ENTRY  [ENTRY  NO]. ALIAS  TABLE  LOC 

alias~taeie~icc 

G  AST [PAR  INDEX] .ALIAS  TABLE  LOCI  :=  ALIA?  TABLE  LOG 
SUCCESS  CODE  :=  WRITE  ALIAS  TABLE  {  ALIAS  TABLE  LOC. 

# ALIAS  TABLE  ^ 

CREATE  ALIAS  TABLE 


t  ##«  %  $  A  *  #  ij«  i/t  $  $  4  tt  44  4  *  4  4  4  4  4  4  $  4  4  4  ajc  4  4  4  4 4  4  4  44  4  *  4  4  4  4  4  4  4  4  4  4  4  >|t  4  4  4  4  * 
*  * 

*  The  CFFC*  MAX_  VIRTUAL.. COPE  Procedure  is  called  * 

*  By  the  la  procedure.  The  procedure  will  verify  that  * 

*  th°  addition  of  the  segment  requested  to  te  swapped  in  * 

*  will  not  cause  the  process'  allocated  virtual  cere  tc  * 

*  Be  exceeded.  If  thevirtual  core  is  not  exceeded,  a  * 

*  success  code  of  valid  is  returned,  otherwise  a  success  * 

*  code  of  no  remory  is  returned.  * 

4  ~  * 

4444  0  44444*4444444444*  *  *  4  4  4  4  $  *  4  *  *  44444  4  4 4 4 4 4 4 4 4 4 4 & 4  4 4 4  *  *  *  4  4  J 

CHECK  MAX  VIRTUAL  CORE  PROCEDURE  (  DBR  NO  BYTE, 

BliTNO  RSO  WORD  ) 

RETURNS  (  SUCCESS _CODE  BYTE  )“ 

ENTRY 

MV,J  IMAGS [DBR  NO]  .BLKS_’JSED  *=  3LK  NO  ?EO 
IF  MmU  IMAGS  [DPR  NO].  BISS  USED  >  " 

MMU  IMAGE  [EBP  NO] .MAX  ELKS  THEN 
M”U  I^AGE-DPR  .NO]  .BISS  USED  ELK  NO  *SC 

SUCCSSS.CODF  7=  VIRTUAl  CORE  FULL  "  " 

EL?F 
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SUCCESS  COD?  :=  VALID 
FI 

?.V*  CHECK  MAX  VICTUAL  CORE 


I  i(;ijti{ti!ti{tiiti(tiic#tjtl}t ijtijt#  lit## i!t#!jtiit>!i$lit>!t#Jitt!tt!t}itijc ijtlit * lit  s|t  ijt  lit  lit#  lit  }[:>!<  lit  #l!s  lit  i|t  lit# j;:^^;  $$ :;tj^j;;>|; 
«  # 

*  The  7FES_?E0C3SS_YIRTUAL_C0RE  Procedure  Is  called  from  * 

*  the  Out  procedure.  The  procedure  will  subtract  the  * 

*  size  of  "the  segment  which  has  been  swapped  out  fror  * 

*  the  virtual  linear  core  allocated  to  that  process.  * 

*  ❖ 
iiti;tt;tt:tt!ii!t:;:&$$$$i;t$ii: $$$$$ »;t ft## $$ $$$$ i;t;;tiiti;ti;ti;n;s >;<»;< 1$$ ftiittyiiti^iit  j 


FREE  PROCESS  VIRTUAL  CORE  PROCEDURE  (  ELK  NO  VOF.I  \ 
“ENTRY 

WU  I MA Gr  [  DPR  NO  ].BLX3  USED  -«  BLK  NO 
?ND  Er*E  PROCESS  VIRTUAL  COR? 


I  i|t  lit  >|:  i|t  i|:  i|t  ;|t  »'t  $$$  i|<i|t  i|t  1  it  lit  $  i|t  tit  lit  #  tit  tit  t|:  i|t  <t  <t  t,:i|t  lit  i|t  i|t  i|:  i;ti|tt|t  iit$t;:$  i|:  i|t  i|t  tit  lit  a;t  i|t  #  i|:  lit  lit  $  i|t  ijt  $  i|t  # 


* 

* 

* 

i|t 

lit 

# 

*■ 

* 


The  FREE_S”C0N  DARYLS  TOP.  AGE  Procedure  is  called  from 
the  D«lete_seg  procedure.  The  procedure  will  read  the 
paee  tahle"of  the  segment  to  be  deleted  and  the 
secondary  storage  bit  map  into  main  memory.  The  bit 
man  will  be  cleared  to  reflect  the  deallocation  of 
secondary  storage,  and  the  pae-e  table  location  will  be 
cleared.  The  procedure  returns  a  success  code  of 
valid  or  invalid. 


* 

»:> 

ijc 

* 

lit 

* 

lit 

lit 


i!t>!ti^i^i^^t>|ti!tiiti!ti^Ai!ti^i;«<;iSi^4(<t^t'iti^^ci^i;t>itiitii«i>i!t^tiiti^iit^t^iiti;t^i^^v>i(*!tii(s!t!!o!t>^i!t>!t<tiitiui.,tiit^>it  1 


FREE  SEC  STORAGE  PROCEDURE  (  PAGE  TABLE  LOC 
RETURNS  (  SUCCESS  CODE  BYTE  1 

TAntT  r  wnnn 

TABLS1  ARRAY  [  BIK  SIZE  WORD  ] 

ENTRY 

SUCCESS  CODE  :=  READ  PAGE  (  PAGE  TA3IE  IOC 
IF  SUCCESS  CODE  O  VALID  THEN 
RETURN 


FI 


,  eTABIEl  ) 


SUCCESS_COUE  :=  READ  DISK  BIT  MAP 
IF  SUCCFSS  CODF  O  VALII  THEN- 
RETURN- 
FI 

I  :=  2 
DO 

I?  TABISlCl]  =  NULL  ORIF  I  >=  212  SIZE  THEN 
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KIT 

FI 

CIEA?.  DISH  SIT  VAF  (  TA3IF1  [I]  ) 

i  +=  r 

or 

CIS A3  DISH  SIT  MAP  (  FAGS  TA3IS  IOC  ) 
SUCCESS  CODE  :=  VALID 
END  FPSE  ESC  STORAGE 


t  ftftftftftftftftftftftftftftftftftftftftftftftftftftftgftftftftftftftftftftftftftftftftftftftftftft  ftftft  *»;< ft  ft  >:••»:< 
ft  ft 

*  The  DELETS_SSG  Procedure  is  called  from  the  Delete  * 

*  entry  procedure.  The  procedure  will  free  secondary  * 

storage  for  the  deleted  segment,  and  null  out  the  * 

entry  ir.  its  mentor  segment's  alias  table.  The  pro-  * 
cedure  returns  a  success  code  of  either  valid  or  in-  # 
valid.  # 

ft 


ftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftft  j 

DELETE  SEG  PROCEDURE  (  ENTRY  NO  WORD  ) 

RETURNS  (  SUCCESS  CODE  BYTE  ) 

ENTRY 

SUCCESS  CODS  :«  FREE  SEC  STORAGE ( 

ILIAS  TABLE. AllAS~ENTRY  fENTRY  NO] .PAGE  TABLE  LOC ) 
IF  SUCCESS  CODF  O  VALID"*  THEN 
RETURN 
FI 

IF  ALIAS  T AIDE. ALIAS  ENTRY [ENTRY  NO] .ALIAS  TABLE  LCC 

<>  NULL  THEN 

CLEAR  KSX  BIT  UA?( 

ALIAS  TABLE. ALIAS  ENTRY  [ENTRY  MC] .  ALIAS  TAKE  LOC'* 
FI- 

llIAS  TABLE. ALIAS  ENT^T [ENTRY  NO], UNIC’JE  ID  :=  NULL 
END  DELETE  *EG 


]  ftftftftftftftftftftft  ftftft  ftft  ft  ftftftftftftftftftft»;:ftftft  ftftft  ft  ftftftftftftftftyftftftftftftftftft  ft 

J. 

The  CESCE_I?_ALIASJ5MFTY  Procedure  is  called  by  the 
Delete^enlry  procedure.  The  procedure  will  search  t 
alias  table  to  determine  if  the  table  is  empty.  If 
alias  table  is  empty,  the  variable  Alias_ta cle_ei’pt 
is  set  equal  to  true  and  returned.  If  the  table  is 

m  m  ft  «»  M  ^  5  <■  ♦  *  V  1  rt  Am  m  4  ,,  (  «  a  n  ^  1  4  ^  ^  1  a  a 


is  3si  m  nue  auu  itrvuiticu.  n  me  '.able  iS 

empty,  Alias_table_empty  is  set  equal  to  false. 

ftftftftftftftftftftftft  ftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftnsftftftftftftftftftftft 


vftftvft 
ft 
ft 
ft 
ft 
ft 
ft 


ne 

the 

y 

not 


* 

v  *■'  f 
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CHECK  IF  All  AS  2*?TY  PROCEDURE 

RETURNS  (  ALIAS  TABLE  EMFTT  BYTE  ) 

LOCAL  I  BYl2 
I  :=  2 
CO 

IF  I  =  AIIAS  TAELE  LIMIT  THEN 
AIIAS  TABLE  EMPTi  :  =  TRUE 
EXIT 

ELSE 

~^"lF  ALIAS  TABLE. ALIAS  ENTRY  [I]  .UNICUE  IDOC  THEN 
ALIA?  TABLE  EMPTt  :=  FALSE 
EXIT  “ 

ELSE 

I  +=  1 
FI 


END  CHECK  IF  ALIAS  EMFTT 


it  *:« 

*  The  CHECK..  IOC  AIJ'^MORY  Procedure  is  called  from  the  In  * 

*  procedure?  The  procedure  determines  if  the  segment  is  # 

*  in  the  processor's  local  memory  by  examining  the  MM*J  # 

*  image  for  ea-h  connected  process.  If  the  segment  is  in  * 

*  the  local  memory,  the  variable  Test  is  set  equal  to  * 

*  true,  otherwise  it  is  set  equal  to  false.  * 

*  * 

CHECK  LOCAL  vEMORY  FROCEDL’RS  (  INCEX  WORE  ) 

RETURNS  (  TtST  BYTE  1 
LOCAL  I  BYTE 

SEG  NO  BYTE 

I  t-2 
DO 

IF  I  *  max  DBR  NO  THEN 

TEST  :=  NOT  IN  LOCAL  mF'-crI 
RETURN 
FI 

SSG  N'C  :=  (  L  AST  [INDEX] .SEGMENT  NO  ACCESS  /UTEfl] 
"AND  *( 2101111111  T 
IF  SSG_NO  <>  e  THEN 

IF  (MMU  IMAGE  [I]  .SDR  [SEG  NO] .ATTBIIUTES  ANT 
IN  MEMORY  MASK  ^  7s  2  THEN 
TEST  :=  IN  LOCAL  MEMORY 
RETURN 
FI 
FI 
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or 


i  +=  i 


END  CHECK  IOC 41  MZMOFY 


f  £  #  i/t  #  >!«  >!«  #  »Je  sj<  $  #  :£ #  Jfc  ft jX  »;< )jt  $  >X>X  ft j,V >X  $  ft $  # #  »*t  >X>X #  >X ft $  ft  ft  # >X $ s(t >X  $ >(j>X>X $  *  $ »X # sjt  ?X  4 

*  *X 

*  The  CR?CF_FOR_RSMOVAL  Procedure  is  called  tv  the  Peact-* 

*  ivate  procedure.  The  procedure  will  determine  if  the  * 

*  se^mpnt  is  active  in  any  l_AST  and  if  it  has  any  active* 

*  dependents.  If  the  sepir.er.t~is  r.ot  active  and  does  not  * 

*  have  any  active  dependents,  the  G_AST  entry  is  removed.* 

*  ”  # 

CHICK  FOP.  RSVCVAI  PROCEDURE  (  INDEX  WORD  ) 

L5CAI~  I  BYTE 
TEST  BYTE 

SNTRy 

TEST  :=  FALSE 
I  :=  f 


DO 


IF  I  *  NO  OF  PROCESSORS  OR I?  TEST  =  TRUE  THEN 
FXIT  ~ 

FI 

IF  G  ASTflNDEX] .PROCESSORS  I  ASTE  NOfll  fc’  THEN 
T^CT  =  TRII7 


or 


T?ST 
FI 

I  +=  1 


I?  G  AST [INDEX] .NO  ACTIVE  DEPENDENTS =? 
AND IF  TEST  =  FALSE  THEN 
G  ASTflNDFZ]  .UNIQUE  III  :=  AVAIIAHE 


FI 


END  CHECK JrO’J.EMOVAL 


[  >X =X # <« $ sX#* 5X»X >X  JX>X:X>XsX>X>X!XsX5XiX>X5X:X #5XsX>X>X>XsXfc>XiX5XsX>X>X>X>:<JX*lX;X 
ft  ft 

*  The  CEEC*_IFJ>THERS_ACTIVE  Procedure  is  called  ty  the  * 

*  Delete_entry  procedure.  The  procedure  will  check  to  * 

*  determine  if  a  segment  is  active  in  any  I_AST.  If  the  * 

*  sepmer.t  is  active,  the  variable  Others^a^t  1  ve  is  set  * 

*  equal  t0  true,  otherwise  it  is  set  eqral  to  false.  * 

*  * 


CFECK_IF„0?KFCS^ACTIVE  PROCEDURE  (  INDEX  WORD  ) 


11? 


(  OTHERS  ACTIVE  BYTE  ' 

LOCAL  I  BITS 
ENTRY 
I  :=  2 
DO 

IF  I  «  NO  OF  PROCESSORS  THEN 
OTHERS  ACTIVE  :=  FALSE 
RETURN" 

FI 

IF  G  AST  [INDEX]  .PROCESSORS  L  ASTE  NO  [I]  O  2  THEN 

Others  active  :=  true  ~ 
return" 

?i 

i  +=  i 
OD 

end  check  if  others  active 


tt  ft 

*  The  ACTIVZ_IN_L_AST  Procedure  is  called  by  the  react-  * 

*  ivate  procedure?  Tho  procedure  will  search  the  Se&-  # 

*  ment  J^/Access^auth  field  of  a  segment  to  determine  if  # 

*  the  segmert  is  active  in  the  L_AST.  If  the  segment  is  * 

*  active,  the  variable  Check  will  be  set  equal  to  True  * 

*  and  returred.  * 

ft  ft 

ACTIVE  IN  I  AST  PROCEDURE  (  INLET  WORD  ) 

RETURNS "(  CHECK  BYTE  ) 

LOCAL  I  BYTE 
ENTRV 
I  :=  ? 

CHECK  :=  FALSE 
DO 

IF  I  *  MAX  EBP.  NO  OR  IF  CHECK  »  TRUE  THEN 
RETURN 
FI 

IF  L  ASTfINDEX] .SEGMENT  NO  ACCESS  AUTH  O  ?  THEN 
CFECE  :=  TrUE 
FI 

I  +=  1 
OD 

END  ACTIVE  IN  I  AST 


|  jJeajtjJr 5^ sic* s^sjs sjs sjs j{s ^tsjcs^  s.^t s 


ft 
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•if-  «■ 


*  The  UPDATE  !•  AST  ACCESS  Procedure  is  called  by  the  In  * 

*  ' procedure. “THe  procedure  will  set  the  read/write  bit  * 

*  of  the  appropriate  septnent_#/access_auth  field  of  the  * 

*  L_AST  to  a  one  if  the  process  has  write  access  or  to  a  * 

*  zero  if  the  process  has  read  access.  # 

*  # 

UPDATE  I  AST  ACCESS  PP0CEDUR2(INnE7  WORD, ACCESS  AtTTH  BYTE, 

DBP  NO  BYTE  ) 

LOCAL  SEC  NO  WORD 
ENTRY 

SEG  NO  :=  L  AST  [INDEX] .SEGMENT  NO  ACCESS  AUTK[D2R  NO] 

IF  ACCESS  AUTH  *  WRITE  THEN 

L  AStTINDEX]  .SEGMENT  NO  ACCESS  AUTH[P2P.  NC]  :  = 

“SEG  NO“  OR  ?(27l WMZZZ 
ELSE  “ 

"l  AST  [INDEX]  .SEGMENT  NO  ACCESS  AUTH  [UR  NO]  :  = 

“  SEG  NO  AND  8^2)011111111 
FI 

END  UPDATE  L  AST  ACCESS 


}  $#>*«  juft*###**  >{<#){:  >)<$#){«  >;:»[« 

<1  * 

*  The  SEAP.CH_G_.AST  Procedure  is  called  by  the  Activate  * 

*  procedure. “The  procedure  will  search  the  G_»ST  to  * 

*  determine  if  a  passed  segment's  unique_id  exists  in  * 

*  the  G_A?T.  If  the  uniqve_id  is  found,  a  success  code  * 

*  of  found  ard  the  G_AST  index  are  returned.  If  the  * 

*  segment  is  not  found,  a  success  cede  of  not_?ound  is  * 

*  returned,  “  * 

<«  <« 

$  $  jjtafe  $»;«£»!«$#*>*(>((  $#*$*!)<#>*  Jit*  #>;<){<  $#*;<>;»  >;<>;<  »;<##>&  j 

SEARCH  G  AST  PROCEDURE  (SEG  ID  IONGWORD) 


RETURNS  ( SUCCESS  BYTE,  INDEX  WORD) 


LOCAL  I 


WORD 


ENTRY 
I  :=  e 
IIOOP:  DO 

IF  I  =>  G  AST  LIMIT  TFEN 
SUCCESS  :="NCT  FOUND 
INDEX  :=  NULL 
RETURN 
FI 

I?  G  AST [I] .UNICEF  IDl  =  SEG  It  THEN 


SUCCESS  :=  FOUND 
INDEX  :=  I 
BET URN 
FI 

I  +*  1 
CD 

END  SEARCH  G  AST 


I  ft#*##  £*)>,  >■«##)!«*##>!< 

ft  * 

*  The  5ET_L_AST_ INDEX  Procedure  is  called  by  the  Ma^e^  * 

*  l^AST^entry  procedure.  The  procedure  vill  search  the  * 

*  l~AST  from  top  down  until  an  available  index  is  found.  * 

*•**  If  an  index  is  not  found,  a  success^code  of  l_A$T_full  # 

*  is  returned.  If  an  index  is  found,  the  index, ~ar.d”a  * 

*  success  code  of  valid  are  returned.  * 

*  “  ft 

ftftftftftftftftftftftsfcftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftft  t 


GET  t  AST  NO  INDEX  PROCEDURE 

RETURN” (  SUCCESS  COTS  iYTE  ,  l  INDEX  WORD^ 

LOCAL  I  WORD 

ENTRY 

SUCCESS  CODE  :*  VALID 
I  :«  0  ~ 

ILOOF:  DC 

IF  I  *>  I  AST  IIKIT  THEN 

SUCCESS  CODE  ;*  I  AST  FULL 
RETURN  ” 

FI 

IF  I  AST f I] .N2KORY  ADDR  =  AVAIIAJLE  THEN 
L”INDEX  :*  I 

i”ast [ i] .Ni^OFY  Arr?  active 

RETURN 

FI 

I  +=  1 
OD 

END  C-ST  L  AST  NO  INDEX 
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J  ft#*#*!!!?  :{<)((>!(##  A**  *#>!« #*# sis#  #$!(«#  # ajojt ## i^x^ fcj^jjs >!<  ft#  ##&###  #*>;<# 

ft  ft 

*  The  GET_G_AST_INEEX  Procedure  is  called  frorr  the  Make_  * 

*  G_AST_eiitry  procedure.  The  procedure  will  search  the  ~  * 

*  G  JtST"f  rom  the  top  down  until  an  available  index  is  * 

*  found.  If  an  index  is  not  found,  a  succe$s_code  of  * 

*  G_AST_full  is  returned.  If  an  index  is  found,  the  index* 

*  and  a”success  code  of  valid  are  returned.  * 

ft  ”  ft 

ftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftft  j 

GET  G  AST  INDEX  PROCEDURE 

RETURN"  (  SUCCESS  COBS  BYTE  ,  INDEX  VOPD) 

LOCAL  I  WORD  “ 

ENTRY 

SUCCL  S  COBS  :*  VALID 

J  ja  ft  ” 

ILOO?:  DO 

IF  I  «U  AST  LIMIT  THEN 

SUCCESS  CODE  :=  G  AST  FULL 
SETUP N 
FI 

IF  G  AST  [I]  .UNIGUID  ID1  =  NULL  THEN 
INDEX  :*  I 
RETURN 
FI 

I  +*  1 
OB 

END  GET  G  AST  INDEX 


t  ftftftftftftftftftftft  ftftftftftft  ftftftftftftftftftftftftftftftftftftftftftftftftftft  ftftftft  ftftftftftftftftftftftft 


The  mASS_G_AST_FNTBY  procedure  is  called  from  the 
Actlvate"procedure.  The  procedure  will  obtain  an 
index  into  the  G_*ST  and  enter  the  anpropriate  data 
from  the  alias  table.  The  fla*  bits  are  set  to  not 
written  and  not  writable.  The  eventcounts  and  ticket 
fields  are  set  to  zero.  The  processor_L_ASTS_#  fields 
are  set  to  null.  If  the  entry  is  successfully  made, 
a  success  code  of  valid  will  be  returned. 


ft  ftftftft  ft  ftft  ft  ft>*;ftftft  ft  ftft  ft  ftftftft  ft  ftftftft  ftft  ft  ftft  ftftftftftftftftftftftft#  ftftftft  ftftftft  ft  ftftftftft  f 

MAKE  C-  AST  FNTRY  PROCEDURE  (FAR  INDEX  WORD, ENTRY  NO  if  CRD ) 
RETURNS- (  SUCCESS  CODS  LYTS, “INDEX  WORD  ) 

LOCAL  I  "WORD 


ENTRY 

SUCCESS  COVE,  INITX  :  =  GST  G  AST  ENTRY 


A** 


I?  SUCCESS  COTE  =  VALID  THEM 

G  AST  [INDEX]  .UNIOUID  ID1  :=  ALIAS  TABLE. ALIAS  JINTP.T  [ 

EM THY  NO]  .UNIOUIB  ID 
G  AST [INDEX] .GLOBAL  A DDR  :  =  ACTIVE 
G_AST  [INDEX] .FLAG  BITS  :  =  G  AST [INDEX] .7LAG_BITS 

AND  (  NOT  WRITTEN  MASK  ) 

G  AST  [INDEX]  .FIAG  BITS  :  =  G  AST  [INDEX]  .TIAGJcITS 

AND  (  NOT  WRITABLE  MASK  ) 

G  AST  [INDEX] .G  ASTE  NO  FAR  :*  PAR_INDRX 
G_AST  [INDEX] .NO  ACTIVE  IN  MEMORY  :=  £ 

G“AS? [INDEX] .NO~ACTIVE” DEPENDENTS  :  =  Z 
G"AST  [INDEX] .SIZS1  ALIAS  TABLE. ALIAS_ENIRY [ 

”  ENTRY  NC  ]  .SIZE 
3  AS?  [INDEX] .PAGE  TABLE  LOCI  :  = 

“  ALIAS  TABLE. All AS  ENTRY  [ENTRY  NO] .FAGr  TABLE_LCC 
G  AS?  [INDEX] .ALIAS  TABLE^LOCl :* 

■  ALIAS  TABLE. ALIAS  ENTRT [ENTRY  NO]  .ALIAS  TA3I2.L0C 
G  AST [IND^Xj . INSTANCSl  :*  0 
G“AS?  [INDEX] .INSTANCE2  :*  0 
G“AST [INDEX] .SECU2NCSR  :=  0 
l'*:=  0 
I LOO*:  DO 

I?  I  »  NO  0?  PROCESSORS  THEN 
EXIT 

fi 

G  AST  [INDEX] .PROCESSORS  L_ASTE_NC[I]  :=  NULL 

!”+«  1 
OD 

SUCCESS  CODE  :=  VALID 
71 

*ND  MAKE  G  AST  ENTRY 


is 

if 

* 

if 

if 

* 

* 

its 

if 

it 


The  MA7’EJL_AS?  ENTRY  Procedure  is  called  from  the 
activate**proce5ure .  The  procedure  will  obtain  an 
index  into  the  L  AST  and  enter  the  appropriate  data. 
The  nemory_addr  field  is  set  to  active,  the  semrr.ent_ 
#/access_auth  fields  are  initialized  to  zero,  and 
the  passed  seerneat  number  is  entered  into  the  ap¬ 
propriate  location.  If  the  entrv  is  successfully 
made,  a  success_code  of  valid  is  returned. 


>:« 

* 

if 

if 

* 

* 

if 

if 

if 

if 


************  *$>*!  ****$*#*$**«***$************#**#*$*«*#«*****! 


MftjT  i  AST  ENTRY  PROCEDURE  (DBR  NO  BYTE,  SEGMENT  NO  WORD) 
RETURNS  (  SUCCESS  CODE  BYTE;  I  INDEX  WORE  ' 

I OCA I  I  BYTE  ~ 
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SSG  NO  WORD 

ENTRY 

SUCCESS  CODE,  I  IND3T  :=  GET  I  AST  INDEX 
IF  SUCCESS  CODE  O  VALID  THEN  "RETURN 
FI 

I  AST  Tt  INDEX] .MEMORY  ADDR  :  =  ACTIVE 
l":=  e 
DO 

1  AST  n.  INDEX]  .SEGMENT  NO  ACCESS  AUTK[I]  :  =  e 

r  +« r 

IF  I  >=  MAX  DBR  NO  THEN  EXIT 
FI  " 

OD 

T.  AST  [I  INDEX]  .SEGMENT  NO  ACCESS  AUTK  [DBR  N0]:=SEGV3NT  NO 
END  MAKE  l"A?T  ENTRY 


{ >S  $  »s  >S  >S  >!i  $  #  >S  *  <<  *  #  tf  #  #  #  if  #  $$$$$$$  >,t  #  »;<  >;<  #$#*,•«»:« 

*  * 


*  The  DEAC?IVATE_AIl  Procedure  Is  called  ty  the 

*  Detete_entry  orocedure  and  hy  the  wain_line 

*  procedure.  The  procedure  will  deactivate  the 

*  deleted  segment  from  all  connected  process' 

*  address  space.  The  G  AST  index  and  the  I..AST 

*  index  for  the  delete?  segment  are  passed  to  the 

*  procedure.  If  the  segment  was  successfully 

*  deactivated  from  all  connected  processes,  a 

*  success  code  of  valid  is  returned. 


$ 

>s 

if 

m 

ft 

>S 


* 

* 

*! 


DEACTIVATE  All  PROCEDURE  (  INDEX  WORD,  I  INDEX  VOFI  > 
RETURNS  (  SUCCESS  CODS  rYTS  ) 

IOCU  I  PYTE 
EN?RT 
I  :=  0 
DO 

IF  I  =  MAX  DPR  NC  THEN  EXIT 
FI 

IF  I  AST  [I  INDEX] .SEGMENT  NO  ACCESS  AUTF [I] 

O  ZERO  TEEN 

SUCCESS  CODE  :  =  DEACTIVAE  (  I,  INDEX  ) 

IF  SUCCESS  CODE  O  SEG  DFACTIVATED  THEN 
RETURN 
FI 
FI 

I  +=  1 
OD 

SUCCESS  CODE  :=  VALID 
END  deactivate  AIL 
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*  * 


*1 


* 
a 
$ 
* 
* 
# 
* 

* 


The  SIGNAL _OTHER_MEMORY_MANAGSR  Procedure  is  called 
by  the  Ir.  procedure.  The  procedure  will  signal 
a  memory  manager  to  move  a  segment  from  its  local 
memory  to  global  memory.  When  the  segment  is  moved 
to  Global  memory  the  procedure  will  signal  all  other 
connected  memory  managers  to  update  their  local 
databases.  The  global  address  for  the  transfer 
is  passed.  A  success_code  is  returned  to  indicate 
the  success  of  the  operation. 


* 

* 

ijt 

# 

* 

!* » 


SIGNAL  OTKEP  MEMORY  MANAGERS  PROCEDURE  ( 

~  SEG  INDEX  WORD,  ADDS  WORD  ) 

RETURNS  (  SUCCESS  CODE  BYTE  ) 

IOCAL 

PROCESSOR  NO  BYTE 
FIRST  "  BYTE 
L  ENTIP  NO  WOP.D 
VALID  MSG  BYT? 

MSG  -  ARRAY  [MAX  MSG  SIZE  BYTE] 

ENTRY 

FIRST  :*  TRUE 
PROCESSOR  NC  ;  =  9 
DO 

I?  PROCESSOR  NO  =  PROCESSOR  ID  THEN 
PROCESSOR  NC  +=  1 

FI 

IF  PROCESSOR  NO  >=  NO  OF  PROCESORS  THEN 
EXIT  “  " 

FI 

L  ENTRY  NO  :=  G  AST [SEG  INDEX] .PROCESSOR  I  AST?  NO  [ 

FROCFSSOR~lP  J" 

I?  L  ENTRY  NO  <>  NULL  THEN 
IF  FIRST  =  TRUE  TEEN 
FIRST  :=  FAISE 
IF  PROCESSOR  NO 
CASS  9  THEN 

SIGNAL  (  V?  ID,  MEMORY  MANAGER  9,  MOVE, 

L  ENTRY  NO, “ADD?.,  G  AST  [SEC-  INDEX], SIZE  * 
7P_ID,  MSG  :=  WAIT 

!  ****  CHECK  I?  VALID  MSG  ***  ' 

VALir_MSG  :=  VALIDATE  WAIT  MESSAGE  f,vSG) 

FI  ~ 

ELSE 
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•>  ->  it 


IF  PROCESSOR  NO 
CASE  ?  THEN" 

SIGNAL (  VP  ID,  MEMORY  MANAGER  f,  UPDATE, 

I.  ENTRY  NOT  ACER,  G  AST  [SEG  INTEX]  .S I ZT  ' 
VP_ID,  MSG  :=  WAIT 

i  *****  chect:  if  vaiid  msg  #*##  ! 

VALir  MSG  :=  VALIDATE  WAIT  MESSAGE(MSG ^ 

FI 

FI 

FI 

PROCESSOR  NO  +=  1 

OD 

IF  VAIID  *SG  THEN 

SUCCESS  CORE  :=  VALID 

ELS7 

SUCCESS  COTE  :=  INVALID 
FI 

END  SIGNAL  OTHER  MEMORY  MANAGERS 


t  *****»)i>!«*****#****it«*****>;<****»l'«***»1,t**************>!«*>;«***8,,«***** 
*  * 


The  CRSATEJ5NTRY  Procedure  Is  called  by  the 
Main  line  procedure.  The  procedure  will  create 
an  entry  irto  the  alias  table  and  allocate  sec¬ 
ondary  storage  for  the  created  se^ent.  If  the 
alias  table  does  not  exist,  the  procedure  will 
create  an  alias  table  on  secondary  storage. 

*  A  uniaue_id  is  assigned  to  the  segment  and  the 

*  appropriate  data  is  entered  into  the  table. 

If  the  function  is  successfully  completed,  a 
success  code  of  segment  created  is  returned. 


* 

* 
ft 

*  ft  ft  ft  $  ;*«  ft  ft  ft  *  *  ft  *  **  *  *  *  * *  *  *  #  #  $  *  y  *  *  *  *  *  * * ft  **  *  *  *  *  *  * **  *  y  *  *  * 


ft 

ft 

ft 

ft 

ft 

ft 

ft 

ft 

ft 

ft 

ft 

***** } 


OPIATE  ENTRY  PROCELURE  (  FAR  INDEX  WORD,  ENTRY  NO  WORD, 
SHE  WORD,  CLASS  2YTE  ) 

.V  .‘i'T’RNS  (  S^CCFSS.CODE  BYTE  i 

LOCAL  PAGE  TABLE  LOC  WORD 
BLYS~  WORD 

ENTFY 

31ES  :=  SIZE  /  BIE_SIZS 

IF  G  AST [PAR  INDEX] .G  ASTS  NO_FAR  <>  ZERO  THEN 

S”CC?SS_COEF  :=  CREATE'AIAIS  TABLEf  FAR  INTFY  > 
IF  SUCCESS  CODS  <>  VALID  THEN 
RETURN  " 

FI 
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2ND 


FI 

SUCCESS  COBS  :=  FEAD  ALIAS  TABLE ( 

G"*AST  [PAR  INDEX]  .ALIAS  TABLE  LOCI,  #AIIAS  TABLE) 
IF  srccfss  ccde"o  VALID  TFFN 
RETURN- 
FI 

IF  ALIAS  TABLE. ALIAS  ENTRY [ENTRY  NO] .UNICUID  IB  O  2 
THEN 

SUCCESS  CODE  :=  DUPLICATE  ENTRY 
RETTT?  N  - 
FI 

PAGEJTABLE_LOC,  SUCCESS  CODE  :=  ALLOC  SEC  STORAGE ( 

“  “  ”  ELKS  ) 

I?  SUCCESS  CODS  <>  VALID  THEN 
RSTURN- 


FI 

ALIAS  TABLE. ALIAS  ENTRY  [ENTRY  NO] .UNIQUE  ID, 

SUCCESS  CODE  :=  GET  UNIO  ID 
IF  SUCCESS  CODE  <>  VALID  THEN 
RETURN- 


FI 


ALIAS  TABLE. ALIAS  ENTRY 
ALIAS “TABLE. ALIAS-EN?RY 

alias“tabls.alias"entry 


ENTRY  NOl .SIZE  SIZE 
ENTRY"N0] .CLASS  :*  CLASS 
ENTRY_NO] .PAGE  TABLE_LOC 
PAGE  TABLE  LOC 

ALIAS  TABLE. ALIAS  SNTRY[ENTRT  NO] .ALIAS  TABIF  LOC  : 
SUCCESS  COD?  :=  WRITE  ALIAS  TABLE (G  ASTlFAR  IKB^X]  . 

ALIAS  TABLE  LOC,  #ALIAS  TA1IE  i 
IF  SUCCESS  CODE  =  VAllD  TH§N 

success  Sods  :=  seg  created 

FI 


0 


CREATE  ENTRY 


1 #  >;*  #  $  $  #  $$>;«>;»  $  v  a  $  .i«  <s  s|«  >*.:  #  $  #  it  >;«  >:« »i!  $  ##  $  $  *  »;i  #  &  >:«  >!*  *;*  jcs*;*  *f  »jt  &  $  #  #  $ 


* 

* 

* 

'S.x 


-»* 

* 

* 

if 


* 

**• 

sjc 

W 


The  DEI.STE_ENTRY  Procedure  is  called  by  the  Vain- 
line  procedure.  The  procedure  will  remove  a  segment 
from  secondary  storage  by  deleting  its  entry  in  its 
mentor  segment's  alias  table  and  deallocating  its 
allotted  secondary  storage.  Before  the  segment  is 
deleted,  the  G_AST  is  checked  to  ensure  that  no  other 
process  holds  the  segment  active,  and  that  the  segment 
is  not  a  mentor  segment.  If  the  segment  is  a  mentor 
segment,  deletion  is  not  allowed.  If  the  segment  is 
active,  those  processes  will  be  signaled  to  deactivate 
the  procedure.  When  the  segment  is  deactivated,  it 
will  be  deleted.  If  the  deletion  is  successful,  a 
success  code  of  seg  deleted  will  be  returned. 


* 

$ 

# 

* 

if 

* 

* 

* 

* 


* 

v 


* 

* 
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DELETE  ENTRY  PROCEDURE  (  PAR  INTET  WORD  .  ENTRY  NO  WORT  ' 
RETURNS  (  SUCCESS  COPE  BYT*  ) 

LOCAL  I  INDEX  W5?.D 
INDEX  WORD 
I  BYTE 

ALIAS  TABLE  EMPTY  BYTE 
OTHERS  ACTIVE  BYTE 

ENTRY 

IE  G  AST [FAR  INDEX] .ALIAS  TABLE  LOCI  O  NULL  THEN 

SUCCESS  CODE  J=  REAE  ALAIS  TABLE  t  G  AST  [PAR  INDEX]. 

AI IAS  TABIE  LOCI,  #ALIAS  TABIE") 

ELSE 

SUCCESS  COri  :=  NO  CHILD  TO  DELETE 
El 

IE  SUCCESS  CODE  O  VALID  THEN 

return” 

El 

ALIAS  TABLE  EMPTY  :=  CHECK  IE  ALIAS  EMPTY 
IF  AI IAS  TABLE  EMPTY  =  TRUE  “THEN  ” 

SUCCESS"  C0DE7  INDEX  :=  SEARCH  G  AST  ( 

“ALIAS  TABLE. ALIAS  ENTRYIenTRY  NO]  .UN I CUE  ID  ) 
IF  SUCCESS  CODE  *  FOUND  “THEN 
I  INDEX  :=  G  AST [PAR  INDEX] .PROCESSORS  L  ASTE  MO [ 
PROCESiOR“lD] 

IE  L  INDEX  O  NULL  “THEN 

SUCCESS  CODS  ;  =  DEACTIVATE  ALL(INDEX,  L  INDEX) 
IE  SUCCESS  CODE  <>  VALID  “THEN 
RETURN 
FI 
El 

OTFERS  ACTIVE  :  =  CHECK  IE  OTHERS  ACTIVE 
IF  OTHERS  ACTIVE  =  TRUE  “  THEN 
SIGNAL  OTHERS  TO  DEACTIVATE  ALL 
FI 
FI 

DEIETE  SEG  (  ENTRY  NO  ) 

ALIAS  TABLE. ALIAS  5NTRT  [ENTRY  NO] .UNICUE  IT  :=  0 
SUCCESS  CODS  ;=  WRITE  ALIAS  TABIE  (  G  AST [PAR  INDEX]. 

ALIAS  TASiS  LOCI,  *ALIAS  TABIE  ) 

IE  SUCCESS  CODE  =  VALID'  THEN" 

SUCCESS  CODE  :=  SEG  DELETED 
?I 
BISS 

SUCCESS  CODS  ?=  DEPENDENTS  EXIST 
El 

END  DEIST?  ENTRY 


127 


-X  X 


J  ftftftftftftftftftftftftftftftftftftftftftftftftftfcftftft#$ft>fcsi<>!(Ji{})t};<$J!<J!,>;t#ft#:fc,}c»!<>;sft#>!t>!tJfc#fts(c>;l)(t 

ft  ft 


ft 


ft 

* 

ft 

ft 


ft 

>5* 

* 

A 

ft 

ft 

ft 

ft 

ft 

ft 


The  ACTIVATE  Procedure  is  called  by  the  Main_line  * 
procedure.  The  purpose  of  activate  is  to  add~a  * 
segment  to  the  user's  address  space.  The  procedure  * 
is  passed  the  segment.#,  the  parent's  handle,  and  * 
the  entry  number  into  the  alias  table  for  the  * 
sesment.  The  procedure  returns  the  size.  * 
class.,  ar.d  the  handle  for  the  activated  segment  * 
The  G_A?T  is  searched  to  determine  if  the  segmert  * 
is  already  active.  If  the  segment  is  active  and  * 
not  in  the  I_AST,  an  entry  is  made  in  the  L_AST  * 
and  the  G  AST  is  updated.  If  the  segment  is’artive  * 
in  both  tKe  G_AST  and  the  L_AST,  the  entries  are  # 
updated.  If  the  segment  vas~not  active,  entries  * 
are  made  in  both  the  G  AST  and  the  I  AST.  # 
If  the  operation  was  successfully  comnleted,  a  * 
success_code  of  seg_activated  is  returned.  # 

ft 


ftft*ftftftftft***##***$>),###,:,*ftftft*ftftftft*ftftftftftftftft#ftftft*ftftftftftftftftftftftftftft  j 


activate  procedure  (dbr  no  byte,  pa?,  index  word, 

ENTRY  NO  WORD,  SEGMENT  NO  BYTE  ) 
RETURNS  (  SUCCESS  COYS  BYTE  ,  G  AST  HANDLE  HANDLE  . 

CLASS  BYTE,  SIZE  WORD  )~ 

IOCAI  I  INDEX  WORD 

ifJPEX  WORD 

ENTRY 

IF  G  AST  [PAR  INDEX] .ALIAS  TABLE  LOCI  O  ZERO  THEN 
SUCCESS  CODE  :*  READ  ALIAS  TABLED  AS? [PAR  INTEX] . 

ALIAS  TASLf  LOCI,  JaIIAS  TABLE) 

ELSE  ' 

SUCCESS  cor?  :*  NO  LEAF  EXIST 
FI  "  -- 

IF  SUCCESS  CODS  <>  VALID  THEN 
FETfTRN~ 

FI 

SUCCESS  CODS  ,  INDEX  :=  SEARCH  G  AST  ( 

ALIAS  TABLE. ALIAS  ENYrY [ENTRY  NO] .UNICUE  ID' 
IF  SUCCESS  CODE  =  FOUND  ~  THEN 

L  INDEX  T=  G  ASTflNDSX] .PROCESSORS  L  ASTE  NO[ 

PROCESSOR  ICT 

IF  I  INDEX  O  NULL  THEN 

L  AST [L  INDEX] .SEGMENT  NO  ACCESS  AUTHfUSa  NO]  := 

SEGMENT  NO 

ELSE 

SUCCESS_CODE,  L  INDEX  :=  MAKE  L  AST  ENTRY  ( 

TER  NO.  SEGMENT  NO  > 

IT  SUCCESS  CODE  O  Vfl.HD  THEN 
RETURN 
FI 
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g  asttinlex]  .processors  i  aste  no[?p.ccessor  id] 

:=  L'IRDEX  " 

FI 

IF  G  AST flNtSX] .ALIAS  TAPIS  LOCI  =  NULL  THEN 
Gj[S?[PAR  INDEX]  .NO”DEPFNlfENT?  ACTIVE  -=  1 

FI 
FLSF 

"SUCCESS  COLE,  INLEX  :*  MAKE  G  AST  ENTRY (ENTRY  NO) 
I?  SUCCESS  COLE  *  G  AST  FULL”  THEN 
RETURN 
FI 

SUCCESS  COLS,  L  INLSX  :=  YAKS  L  AST  ENTRY  ( 

PAR  INLEX,  ENTRY  NO  > 

IF  SUCCESS  COLE  =  L  AST  FULL  "THEN 
RETURN  " 

FI 

G  ASTTINLEX) .PROCESSORS  L  ASTE  NO[P?OCSSSOP  It]  := 

I  INLEX” 

FI 

SUCCESS  COLE  :*  SEG  ACTIVATSL 
SI2E  :  =  ALIAS  TABLE. ALIAS  KN?*T [ENTRY  NO]. SITE 
CLASS  :*  AIIAS'TABLE. ALIAS_ENT?Y [ENTRY"NOj  .CLASS 
G  AST  HAN DIE. UNICUE  IL2  :=G  AST [INDEX] tUNICUS  IDl 
G~AST"FANDLE. INLEX  T«  INLEX” 

FNL  ACTIVATE 


*  * 

*  The  SVA?_OUT  Procedure  is  called  by  the  l*ain_line  * 

*  procedure  or  the  reactivate  procedure.  The  ”  * 

*  procedure  will  rerove  a  segment  from  main  memory  * 

*  and  store  it  on  secondary  storage.  The  procedure  * 

*  is  passed  the  process'  L5R_#  and  the  G_AST  index  * 

*  for  the  segment  to  ta  swapped  out  of  memory.  * 

*  A  success_code  is  returned  to  indicate  the  success  * 

*  of  thy  operation.  The  procedure  removes  the  * 

*  segment  from  the  process'  MMU_Image  and  if  not  * 

*  shared,  it  is  returned  to  secondary  storage  * 

*  and  memory  deallocated.  Shared  segments  remain  in  * 

*  memory  until  all  processes  have  swapped  the  segment  * 

*  out  of  main  memory.  * 

$  $ 


SWA?  OUT  PROCEDURE  (  i-PR  NO  BYTE,  INLEX  WORD  ) 
RFT,TRN?  (  SUCCESS  COLE  BYTE  ) 

IOCAI  BIXS  WORD 

I  INLEX  WORD 
SEG  NO  WORD 
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?NT^Y 

ItIMT>VX--5AASTClN?lxifilQCSS30REiSIsTS_NO[PBOCS.SSOJ_IBl 
SfG  «0  ;;VisT[riNBH]  .3EG«Nf  HO.ACCESS.AUTRtMf.NOj 
ypjE  TJPOCSSf  VIRTTJAL_CORE  (  BIXS  ) 

DELETE  M MU  ENTRY  (  DBR._NO,  SEG_NO  ) 

G_AST[INDEX].?IAGJBLTS  :=  G^AST [INDEI]  .HAG^HTS^OR 

IT  G  AST  [INDEX]  ,GLOBAL_ADDR  *  NULL  THEN'  _  „„ 

t ?  p  iCTriND^Tl  MO  ACTIVE  IN  MBvORY  *  v  h^uit 
If  t*:»n[iSsnl:nB:MM'ti«  MITTSN.MASK)  O  0 

?r*socc»s.coi>s  «.  • 

memory_addr  ) 

IF  SUCCESS  CODE  <>  VAIIB  THEN 
RETURN 

FHSE.IOCAl_BIT.MAP  (  I.AST  [I.INDEJ]  .MEMOP.T.tMP.. 
E1$IF  G  ASTtlNDSIl.HO.ACTITJ.IN  MSMOPT  *  e  TEFN 

F*EE  LOCAL  BIT_MAF  (  n 

-  "  memory. ADD?,  ILXS  > 

FI 

FI 

r  icrTTun^Yl  MO  ACTIVE  IN  MEMORY  *  0  ANDIE 

U  *s5tiwS)En;o.lns  5n51»bitten.mase)  o  « ;  n«« 

“  cneC^S  COTE  •*  WRITS_SEGM?NT  (  G  A S T JT I NB. X].  ^ 

"pASE  TABLE  LOCI ♦”G_AST [INDEX!. GLOaAL_ADER  , 

IF  SUCCESS  CODE  <>  VALID  THEN 
RETURN 

FRSS_GLOBAL_BIT_MAP  (  G_AST [INDEX] . GIOEAL_ADDR , 

E1St?  G  ASTriNDSX3.N0  ACTITS.IN.KWOST  =  6  THEN 

FRE1S_GLC B AL _B I T _M  AP (  G.ASTtlNDEX)  ,C-I0BAL_ADDR . 

FI 

FI 

FI 

SUCCESS_CODE  :=  SWAPPED .OUT 
EMD  SWA?  OUT 


T'  I* 
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* 

* 

# 

* 

* 

# 

* 

* 

* 
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The  DEACTIVATE  Procedure  is  called  by  the 
the  Main_line  procedure,  the  Deactivate_all 
procedure,  or  the  Delete_entry  procedure. 

The  purpose  of  deactivate  is  to  remove  a  segment 
from  a  process'  address  space.  The  segment  is 
removed  by  deleting  the  segment  number  from  the 
L  AST.  If  no  other  processes  have  the  segment 
active  and  no  children  are  active,  the  entry 
is  removed  from  the  L_AST  and  the  G_AST. 

The  process'  DBR_#  and  the  deactivated  segment's 
G^AST  index  are  passed  to  the  procedure.  A 
success_code  is  returned  to  indicate  the  success 
of  the  operation. 


* 

* 

* 

* 

* 

* 

& 

a 

* 

* 

a 


c 


DEACTIVATE  PROCEDURE  (  DBR  NO  BYTE,  INDEX  WORD  ) 

RETURNS  (  SUCCESS  CODE  "BYTE  ) 

LOCAL  L  INDEX  WORD 

SZG  NO  BITE  , 

CHECK  BYTE 
PAR  INDEX  WORD 

ENTRY 

FAR  INDEX  :*  G  AST[INDEX].G  ASTE  NO  PAR 
L  INDEX  :«  G  AST [INDEX) .PROCESSOR  L~ASTE  NO[?ROCESSOR  ID) 
SEG  NO  :=  L  KST[L  INDEX)  .SEGMENT  fJO  ACCESS  AUTH[DBR  N(5) 

IF  ”G  AST  [INDEX). NO  ACTIVE  IN  MEMORY  O  2  ~TE*N 
IF"(MMU  J.MAGE[CBR  N0].SDR[S3G  NO)  .ATTRIBUTES  AND 

""  IN  MEMORY  RASK)  =  ZERO  THEN 
SUCCESS  CODE  :=  SWAP  OUT  T  DBR  NO,  INIEX  \ 

IF  SUCCESS  CODE  O  SWAPPED  OUT  THEN 
RETURN  " 

FI 

FI 

FI 

L  AST [L  INDEX)  .Stfc?u.«T  NO  ACCESS  AUTHfDBR  NO]  2 
CHECK  :=  ACTIVE  IN  L  ASTCL  INDEX  ) 

IF  CHECK  =  0  THEN  ~ 

I  AST [I  INDEX] .MEMORY  ADDR  :  =  AVAII ABLE 
FI 

IF  PAP.  INDEX  <>  0  THEN 

G  AST [PAR  INDEX]  .NO  ACTIVE  DEPENDENTS  -=  1 
CHECK  FOP._REmOVAI  ("FAR  INDEX  } 

FI 

CHECK  FOR  REMOVAL  (  INDEX  ) 

SUCCESS  CODE  :=  S2G  DEACTIVATED 
END  DEACTIVATE 


I 
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The  MOVE_TO_GLOEAL  Procedure  is  called  by  the 
Main_line  procedure.  The  procedure  is  called  to 
to  move  a  shared  and  writable  segment  to  global 
memory.  The  procedure  is  passed  the  L_AST  index, 
the  size,  and  the  global  address  for  the  move. 

A  success  code  is  returned  to  indicate  the 
success  o?  the  operation.  The  procedure  locates 
the  segment  in  its  local  memory,  transfers  the 
segment  to  global  memory,  and  deallocates  the 
local  memory. 


* 

* 

* 

* 


MOVE  TO  GLOBAL  PROCEDURE  (  L  INDEX  WORD,  GLOBAL  ADDR 

ADDRESS,  SIZE  WORD  7 
RETURNS  (  SUCCESS  CODE  BYTE  ) 

LOCAL  SEC,  NO  "BYTE 
I  "  BYTE 

ENTRY 

MEMORY  MOVE  (  L  AST[l  INDEX] .MEMORY  ADDR ,  GLOBAL  ADLR, 

SIZE  )" 

L  AST [L  INDEX] .MEMORY  ADDR  :*  ACTIVE 
I”:-  C  " 

DO 

U  I  *  MAX  DBR  NO  THEN  EXIT 
FI  “ 

SEG  NO  ;=  L  AST [L  INDEX] .SEGMENT  NO  ACCESS  AUTFfl] 

AND  %T2)01111111 

IF  SEG  NO  <>  t  ANDIF  (MMU  iMAGEfl]  .SDR[SEG  NO]. 

ATTRIBUTES  AND  IN"*EMGRY  MASK)  *  V"  THEN 
MMU  IMAGE  [I]  ,SDR[SEG  N0]TBASE  ADDR  :=  GLOBAL  ADr?. 
FI 

I  ♦-  1 
OD 

FREE  10CAI  BIT  MA?  (  I  ASTfLINDEX] .MEMORY  ADDR,  BLKS  \ 
SUCCESS  CODS  :=  VALID  " 

END  MOV  TO  GLOBAL 


I***#####*##############*#*##**#*######*###****#***********# 
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The  SWAF_IN  Procedure  is  called  by  the  Mainline 
procedure.  The  procedure  will  transfer  a  segment 
from  secondary  storage  to  main  memory.  The  procedure 
is  passed  the  process '  D2?_#,  the  segment  '$  G_AST 
index,  and  the  authorized  access  to  the  segment. 

A  success_code  is  returned  to  indicate  the 
success  of  the  operation.  (  successful  P  swapped^in  ) 
If  the  segment  is  r.ot  already  in  memory,  the  appro- 
priate  memory  is  allocated  and  the  segment  is  trans- 
fered  to  the  allocated  memory.  If  the  segment  is 
writable  and  shared,  the  segment  is  transfered  into 
global  memory. 


$ 

* 

* 

tr 

* 

# 

tt 
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ft#  ftft#ftftftftftftftftftftftftft***ft#ft##<«###$##fr*#*#**#*##**>!<*tt#*»!‘>!'*,*«***! 

SWAP  IN  PROCEDURE ( INDFX  WOHE.rBR  NO  BITE, ACCESS.AUTR  BITE ) 
RETURNS  (  SUCCESS  COBS  BYTE  ) 

LOCAL  3LKS  WORD; 

TEST  BYTE 
SEG  NO  3TTE 
L  INDEX  WORD 
EASE  A DDR  ADDRESS 

ENTRY 

3LKS  :*  0  AST [ INDEX]  .SIZE  /  3LKJIZE 
L  INDEX  * *5  AST  [INTEX]  .PROCESSOR  L  ASTE.NO  [PROCSSSOR.ir] 
SiG  NO  :*  I  ASTU  INDEX]  .SEGMENT  NO  ACCESS  A’JTE  [DBP.^NO] 
SUCCESS  CODS  :*  CPFCK  MAX  VIRTUAL  CQRE  {  DlR  NO,  BUS  ; 
IF  SUCCESS  CODE  »  VIRTUAL..CORS JJJll  THEN 

RETURN 
FI 

G  AST  [INDEX] .NO  ACTIVE  IN  MEMORY  +*  1 
IF  ACCESS  AUTK"*  WRITE  THEN 

G  AST  [INDEX] .FIAG  BITS  :=  G  AST  [INDEX] .FLAG_BITS  OR 

WRITABLE  MASK 


?  ) 


IF  TEST  <>  IN  LOCAL  MEMORY  THEN 

SUCCESS  CODETBASS  ATDR  :=  ALLOC  LOCAL  MEMORY ( ILKS 
IF  SUCCESS  cods""-  iocal^msmory_full”  THEN 

2\imvvnu  ~  ~ 

IV  w*  w  «,n 

ri 

SUCCESS  CODE  :=  READ  SEGMENT  (  G  AST [ INLFX] . 

"FACE  TABLE  LOCI,  BASE  ADDR  ) 
I?  SUCCESS  CODE  <>  VALIT-  THEN" 

FREE  LOCAI  BIT_MA?  (  BASE  ADDR ,  BIES  ) 

RETURN 
FI 
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I  ASTfL  INCH]  .MEMORY  AM*  :=  IAS F  ADDR 
ELSE- 

BAS?  ADDR  :=  I  AST [L  INDEX] .MEMORY  ADDR 
FI 

ELSE 

IF  G  AST [INDEX] .GLOBAL  ADDR  =  NULL  THEN 

SUCCESS  CODS,  BASE  ADDR  :  =  ALLOC  GLOBAL  MEMORY f 

~  ELKS  ) 

IF  SUCCESS  CODE  *  GLOBAL  MEMORY  FULL  THEN 
RETURN 
FI 

IF  TEST  *  IN  LOCAL  THEN 

SUCCES5  COLE  :=  MOTE  TO  GLOBAL  (  L  INDEX, 

BASE"ADD?.,G  AST [IN'EiX]  .SIZED 
IF  SUCCESS  CODE  <>  VALID  THEN 

FREE  GLOBAL  BIT  MA?  (  BASE  ADDR,  ILFS  > 
RETURN 
FI 
ELSE 

SUCCESS  CODE  :» 

SIGNAL  OTHER  MEMORY  MANAGERS (INDEX, BASE  ADDR) 
IF  SUCCESS  CODE  0~VALIB  THEN 
RETURN 
FI 
FI 

ELSE 

BASE  ADDR  J*  G  AST [INDEX] .GLOBAL  ADDR 
FI 
FI 

UPDATE  MMU  IMAGE(DBR  NO,  SEG  NO,  3ASS  ADDR,  ACCESS  AUTK, 

BLKS  ) 

UPDATE  I  AST  ACCESS  (  L  INDEX,  ACCESS  AUTK,  DIF  NC  ) 
SUCCESS  fODB'i*  SNAPPED~IN 
END  SWAP  IN“ 


*  * 

*  The  MOVEJTO_LOCAI  Procedure  is  called  by  the  Main_  * 

*  line  procedure.  The  procedure  is  called  when  ”  * 

*  a  segment  no  longer  needs  to  be  in  Global  memory  * 

*  and  can  be  moved  to  local  memory.  The  procedure  * 


*  is  passed  the  L„AST  index,  size,  and  glcbal  address  * 

*  of  the  segment  to  be  moved.  A  success_code  is  returned  * 

*  to  indicate  the  success  of  the  operation.  * 

*  * 


MOVE  TO  LOCAI  PROCEDUPS  (  I  INDEX  WORD,  GLOBAL  ADDR 

ACTRESS ,  SIZE  WORr  T 
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■RSTUHNS  (  SUCCESS  COBS  BYT 3  ) 

LOCAL  BASS  ADDRESS  ADDRESS 
SBC-  NO  BYTE 
I  "  BYT3 

BLZS  BYTE 

ENTRY 

BLKS  :=  SIZE  /  BLE  SIZE 

SUCCESS  CODE,  BASE  ADDRESS  :  =  ALLOC  LOCAL  MEM0FY(B1KS ) 
I?  SUCCESS  CODE  <>  VALID  THEN 
RETURN 
FI 

MEMORY  MOVE  (  GLOBAL  ACER,  BASE  ADDRESS,  SIZE  ) 

L  AST [L  INDEX] .MEMORY  ADDR  :*  BASE  ADDRESS 
l“j*  ? 

DO 

IF  1  =  MAX  DBR  NO  THEN  EXIT 
FI 

SEC-  NO  :*  L  AST  [L  INDEX]  .SEGMENT  NO  ACCESS  AUTF  Fl] 
AND  ¥(2Teillllll 

IF  SEG  NO  <>  C  ANDIF  (MMiJ  IMAG2[I]  ,SDR[SEG  NO].  ' 

“  ATTRIBUTES  AND  lU  MEMORY  MASK )  =  l  THEN 
MMU  IMAGS[I] .SDRlSEG  NOj.BASE  ADDR:*3ASE  ADDRESS 
FI  " 

I  +«  1 
OD 

SUCCESS  CODE  *  VALID 
END  MOVE  TO"LOCAL 


j  ft  ».<  ft  ft  ft  ft  ft  ft  ft  ■,*<  ft  ft  ft  ft  ft  ft  ft  ft  ft  ft  ft  ft  ft  ft  ft  ft  ft  ft  ft  $  ft  ft  ft  ft  $  ft  ft  ft  ft  ft  ft  ft  ft  ft  ft  ft  ft  ft  >;«  ft  *  ft  Jin’,!  * 


ft  # 

#  The  UFDATE  Procedure  is  called  by  the  Mainline  * 

R  procedure.  Tne  procedure  is  called  to  update  the  * 

*  Mmp  images  o?  process'  connected  to  a  segment  * 


*  that  was  moved  to  global  memory  by  the  Move_to_global  * 

*  procedure.  The  procedure  is  passed  the  L_AST  irdex  , 

*  the  size,  and  the  global  address  of  the  segment  * 

*  that  was  moved  to  global  address.  A  success_code  * 

*  is  returned  to  indicate  the  success  of  the  operation.  * 

*  ft 
ftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftft  J 


UPDATE  PROCEDURE  (  L  INDEX  WORD,  GLOBAL  ADDR  ADDRESS, 

SIZS  WORD  ) 

RETURNS  (  SUCCESS  CODS  BYTE  ) 

LOCAL  SEG  NG  FYTE 
BT  KS  BYTE 

I  BITS 

ENTRY 
I  :=  £ 
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DO 

IF  I  =  MAX  DBH  NO  THEN  EXIT 
FI 

SEG  NO  {*  L  ASTfl  INDEX] .SEGMENT  NC  ACCESS  AUTKflj 
AND  %T2)0111illl 

IF  SEG  NO  <>  0  ANDIF  (MMU  I  MAG"  I].SER[SSG  NC] . 
ATTRIBUTES  AND  IN  MEMORY”mASK;  =  0  THEN 
MMU  IMAGEfI] .SDR[S2G  NO]7bASS  ADDR  :=  GLOBAL  ADDR 
FI 

I  +*  1 
OD 

BLES  :*  SIZE  /  BLK  SIZE 

F^EE  IOOAL_BIT  MA?T  L  AST[L_INDEX] .MEMORY  ADDR ,  BLKS  ) 

L  AST fL  INDEX] .MEMORY  ADDR  :=  ACTIVE 
SNCCESS’CCDE  *  *  VAIIT” 

'NT  UPDATE 


!  *****  MAIN  LINS  CODE  *****  | 

^SECTION  MAIN 


i 


MAIN  LINE  PROCEDURE 

LOCAL  FUNCTION  BYTE 

ARGUMENTS  ARRAY  t  ???  3HS] 

MSG  ARRAY  [MAX  MSG  SIZE  BYTE] 

V?  ID  BYTE  "  “ 

SUCCESS  CODE  BYTE 

ENTRY 

INITIALIZE  PROCESSOR  LOCAL  VARIABLES 
DO 

CHECK  MSG  CUEUE 
VP  ITT  MSG  ;=  WAIT 

!  ***  VALIDATE  THE  MSG  FROM  AIT  ***  ! 

FUNCTION,  ARGUMENTS  :  =  VALIDATE  MSG  (  MSG  ) 

IF  FUNCTION 

CASE  CREATE  ENTRY  THEN  SUCCESS  CODE  := 

CREATS~ENTRY( ARGUMENTS) 
CASE  EELETS  ENTRY  THEN  SUCCESS~CODE 

DELETE_ENTRY( ARGUMENTS ) 

CASE  ACTIVATE  THEN  SUCCESS  CODS, HANDLE, CLASS .SIZE  : 

ACTIVATE (ARGUMENTS ) 

CASE  DEACTIVATE  THEN  SUCCESS  CODE  :* 

deacti7ate(ap.guments  ) 

CASE  SWAP  IN  THEN  SUCCFSS  CODE  :  = 

SWAP  IN (ARGUMENTS) 

CASS  SWAP  OUT  THEN  SUCCESS  CODE  := 

SWAP  OUT ( ARGUMENTS ) 
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C  AS  B 
CASE 
CASE 
CASE 


MOVE  TO  IOCAL  THEN  SUCCESS  CODS  := 

-  -  MOVE  TO  LOCAL (ARGUMENTS) 

MOVE  TO  GIOEAL  TEEN  SUCCESS  CODE  := 

-  “  vrwm  GT.n«AT,(  ARGUMENTS 


UPDATE  THEN  SUCCESS  CODE  := 

UPDA?E( ARGUMENTS) 

DEACTIVAE  ALL  THEN  SUCCESSJJODE  := 

DEACTIVATE_ALL (ARGUMENTS 


) 


/ 


SIGN^I  (  V?  ID,  SUCCESS  CODE,  ARGUMENTS  ) 
OD 

ND  MAIN  LINE 

ND  MEMORY  MANAGSR_PLZ_SYS  MODULE 
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APPENDIX  5  -  PLZ/ASM  SOURCE  LISTINGS 


j***###****#***#*#*##*##*##*#*##*#*#***#*##*##***##******#* 

l  THE  PLZ/ASM  MODULE  WAS  WRITTEN  TO  PROVIDE  SUPPORT  FOR 
1  THE  SWAP  IN  THREAD  [APPENDIX  3] .  THE  VALIDITY  OF  THE 
!  CODE  EAS'NQT  BEEN  THOROUGHLY  TESTED,  NOR  HAS  IT  BEEN 
!  OPTIMIZED.  THE  CODE  SIMULATES  SECONDARY  STORAGE  IN 
!  MAIN  MEMORY,  AND  WAS  NOT  INTENDED  TO  BE  USED  IN  AN 
!  ACTUAL  SYSTEM  IMPLEMENTATION. 

M_MGR_2  MODULE 


,  *  *  *  *  VERS.  1.0  *  *  *  *  ! 


CONSTANT 


FALSE  :=  0 

TRUE  :»  1 

AVAILABLE  :=  0  l  AST  ENTRY  AVAILABLE  l 

ACTIVE  :»  1  i  AST  ENTRY  ACTIVE  ! 

ZERO  :«  0 

NULL  :  =  *0000 

NULL  PAGE  :»  0 

HBUG"  :*  %A900 

MONITOR  :»  *059 A 


!  SUCCESS  CODES  ! 


INVALID  :«  0 

VALID  :=  1 

,  FOUND  ;«  2 

■ffl  NOT  FOUND  3 

SWAPPED  IN  :=  4 

SWAPPED  OUT  :»  5 

SEG  ACTIVATED  6 

SEG  DEACTIVATED  :  =  7 

A  SEG 'CREATED  :=  8 

j  SEG" DELETED  ;»  9 

LEAF  SEG  EXISTS  ;=  10 

.j  NO  LEAF  EXISTS  :*  11 

J.-  G  AST  FULL  :  =  12 

{,  1  L"AST"?ULL  :  =  13 

!  IN  LOCAL  MEMORY  :=  14 

NOf  IN  LOCAL  MEM  :=  15 

■  LOCAL  MEMORY'fULL  :=  16 

j  ■  GLOBAL  MEM  FULL  :=  17 

*  VIRTUAL  CORE  FULL:*  18 

'■!  ■  DUPLICATE  ENTRY  :=  19 
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NO  CHILD  TO  DEL  :=  20 

SEC  STOR'FULL  :=  21 

DISK  ERROR  :=  22 

ALIAS  DOES  NOT  EXIST  :*  23 

!  ATTRIBUTE-MASKS  ! 

READ  MASK  :=  '1(2)11111110 

WRITE  MASK  :»  3(2)00000001 

CHANGED  MASK  :  =  3(2)01000000 

IN  MEMORY  MASK  i=  3(2)00000100 

CLEARED  :*  0  !  CLEAR  ATTR  ! 

!  AUTHORIZED  ACCESS  ! 

READ  :=  0 

WRITE  •«  i 

EXECUTE  :=  3(2)00001000 

I  G  AST  FLAG  BITS  FIELD  MASKS  l 

WRITABLE  MASK  :*  *(2)00000010 

WRITTEN  MASK  :»  3(2)00000100 


l  DESIGN  PARAMETERS  ! 

BLK  SIZE  :=  128 

MAX” PAGE  SIZE  • “  BLK  SIZE/2 

NO  OF  PROCESSORS  :  =  1 

MAX  DBR  NO  :*  4  !  EVEN  NC.  OF  DBR  #'S  I 

G  AST  LIMIT  }»  16  !  MAX  ENTRIES  IN_G  AST  ! 

L“AST  LIMIT  :*  16  \  MAX  ENTRIES  IN  L“AST  l 

MAX  ENTRY  NO  :»  10  !  SIZE  CF  ALIAS  TABLE  ! 

NO  SEG  DESC_RSG  :«  3  !  NO.  OF  SEGMENT/PROCESS! 

FST  POSS  FREE  BLK:*  1 

DISK  MEM' BASE-  :«  39000 

MAX  POSS'D  BLKS  :»  96 

GLOBAL  MEM’ BASS  :=  38000 

MAX  POSS  G  BLKS  :*  32 

LOCAL  MEM  BASE  :=  36000 

MAX  POSS  L  BLKS  :=  64 

DISK  BIT'MAP  LOC  :»  0 

TYPE 

ADDRESS  WORD 

alia:  header  record  [ 

SEG  PAGE  TABLE  LOC  WORD 
PARlALIAS_TA3L2_L0C  WORD  ] 

SEG  DESC  REG  RECORD  [ 

BASE  ADDR  ADDRESS 
LIMIT  BYTE 

ATTRIBUTE  BYTE  1 


ALIAS 


RECORD  [ 

UNIQUE  ID  WORD 
CLASS  “  WORD 
SIZE  WORD 


■\  ; 

'b: 

H 

*  a 
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PAGE  TABLE  LOC  WORD  , 
ALUS.TABLS.LOC  WORD  ] 

RECORD  [ 

SDR  ARRAY  [NO.SEG.DESC  REG 
SEG  DESC.REGJ 
3LKS  USED  WORD 

MAX  BLKS  WORD] 


GLOBAL 

!$SECTION  G.DATA  J 

GLOBAL  MEM  BIT  MAP  ARRAY  [MAX.POSS.G.BLKS/16  WORD] 
G.AST.LOCX"  “  BYTE 

!  ^SECTION  l .DATA  ! 

MMU  IMAGE  ARRAY  [MAX_DBR.NO  MMU] 

LOCAL  MEM  BIT  .MAP  ARRAY  [MAX_POSS_L_BLKS/16  WORD] 
ALIAS~TABL,r.  **  RECORD  [  READER  ALIAS.BEADER 
“  ALUS  ENTRY  ARRAY 

[MAX  ENTRY. NO  ALIAS]  ] 
DISK  BIT  MAP  BUFF  ARRAY  L6  BYTE] 

PAGElTABLE. BUFFER  ARRAY  [BLK.SIZE  BYTE] 


INTERNAL 

COMPACT  L  PROCEDURE 
ENTRY 

END  COMPACT.L 


COMPACT  G  PROCEDURE 
ENTRY 

END  COMPACT. G 

GLOBAL 

ALLOC  LOCAL  MEMORY  PROCEDURE 

1*******%******************************* 
l  PASSED  PARAMETER 
l  R0  *  BLKS  OF  MEMORY 

!  RETURNED  PARAMETERS 
!  R0  «  SUCCESS  CODE 

!  R1  »  BASE  ADDR 

J  LOCAL  VARIABLES 
!  R0  a  BLKS 

!  R10  *  BIT  MAP  INDEX 

l  Rll  *  COUNTER  FOR  BIT 

l  R12  *  BIT  MAP  WORD 

1  R13  a  WORKING  REGISTER 
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LOCAL  BLKS  WORD 

IS  COMPACTED  BITE 
FILLER2  BITE 

ENTRY 

LD  BLKS,  R0 

LD3  IS  COMPACTED,  #FALSE 
LD  R10;  #ZERO 
DO 

CP  R10 ,  #{ MAX  POSS  L  BLKS/16 ) 

IP  EQ  THEN 

CPB  IS  COMPACTED,  #FALSE 
IF  EQ  'THEN 

CALL  COMPACT  L 
LD  R10,  #ZERO 
LD3  IS  COMPACTED,  #TRUE 

ELSE 

LD  R0,  #LOCAL  MEMORY  FULL 
RET 
FI 
FI 

LD  Rll,  #ZERO 

LD  R12,  LOCAL  MEM  BIT  MAP(R10) 

DO 

BIT  R12,  Rll 
IF  Z  THEN 
DEC  R0,  # 1 

ELSE 

LD  R0,  BLKS 
FI 

CP  R0,  #ZERO 
IF  EQ  THEN 
LD  Rl,  R10 
MULT  RR0,  #16 
ADD  Rl,  Rll 
SUB  Rl,  BLKS 
MULT  RR0,  #BLK  SIZE 
ADD  Rl,  #LOCAL"MEM  BASE 
LD  R0,  #VALID  ' 

LD  R13,  BLKS 
DO 

LD  R12,  LOCAL  MEM  BIT  MAP(R10) 

DO 

SET  212,  Rll 
DEC  R13,  #1 
DEC  Rll,  #1 
CP  R13,  #ZERO 
IF  EQ  THEN 

LD  LOCAL  MEM  BIT  MAP(R10),  R12 
RET 
FI 
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CP  Rll,  #ZERO 
IF  EQ  THEN 

LD  LOCAL  MEM  BIT  MAP(R10),  R12 
L D  Rll,  #15  ' 

DEC  R10,  #1 
EXIT 
FI 
OD 
OD 
FI 

INC  Rll,  #1 
CP  Rll,  #16 
IF  EQ  THEN 

LD  Rll,  #ZERO 
EXIT 
FI 
OD 

INC  R10,  #1 
OD 

END  ALLOC  LOCAL  MEMORY 


FREE.LOCAL  BIT  MAP  PROCEDURE 

j  411)14141  **$*$#$**#***4**##**«  ***#*#*#$  j 

!  PASSED  PARAMETERS  ! 

!  R0  *  BASE  ADDR  ! 

!  R1  «  BLKS”  ! 

!  LOCAL  VARIABLES  l 

S  R10  «  COUNTER  FOR  BIT  RESET  ! 

I  Rll  =  BIT  MAP  INDEX  ! 

I  R12  =  BIT  MAP  WORD  ! 

I #**********#$****#«****************#**$ j 

ENTRY 
CLR  R10 
LD  Rll,  R0 

SUB  Rll,  #LOCAL  MEM  BASE 
DIV  RR10,  #BLK  SIZE#16 
DO 

LD  R12,  LOCAL  MEM  BIT  MAP(RU) 

DO 

RES  R12,  r40 
DEC  Rl,  #1 
CP  Rl,  #ZERO 

IF  LT  THEN 

LD  LOCAL  MEM  BIT  MAP(Rll),  R12 

RET 
FI 

INC  R10,  #1 
CP  R10,  #16 

IF  EQ  THEN 

LD  LOCAL  MEM  BIT  MAP(Rll),  R12 
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LB  Bit*.  #ZERO 
EXIT 
El 
OB 

INC  Rll,  #1 
OB 

ENB  FREE  LOCAL  BIT  MAP 


FREE_GLOBAL_BIT  MAP  PROCEBURE 

I  PASSEB  PARAMETERS 
!  R0  *  BASE  ABBR 

!  R1  =  BLKS’ 

!  LOCAL  VARIABLES 
!  R10  -  COUNTER  FOR  BIT  RESET 

!  Rll  =  BIT  MAP  INBEX 

l  R12  *  BIT  MAP  WORB 


ENTRY 
CLR  R10 
I.B  Rll,  R0 

SUB  Rll,  #GLOBAL  MEM  BASE 
BIV  RR10,  #BLK  SIZEn6 
BO 

LB  R12,  GLOBAL  MEM  BIT  MAP(Rll) 
BO 

RES  R12,  RIS 


DEC 

R1 

,  #1 

CP 

Bl, 

#ZERO 

IF 

LT 

THEN 

LB 

GLOBAL  MEM  BIT  MAP(Rll),  R12 

RET 

FI 

INC  R10 ,  #1 
CP  R10,  #16 
IF  EQ  THEN 

LB  GLOBAL  MEM  BIT  MAP(Rll),  R12 
LB  310,  #ZERO 
EXIT 
FI 
OB 

INC  Rll,  #1 
OB 

ENB  FREE  GLOBAL  BIT  MAP 
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ALLOC  GLOBAL  MEMORY  PROCEDURE 

!  PASSED  PARAMETER 
I  R0  =  BLKS  OP  MEMORY 

J  RETURNED  PARAMETERS 
!  R0  *  SUCCESS  CODE 

!  R1  =  BASE  ADDR 

l  LOCAL  VARIABLES 
!  R0  «  BLKS 

J  R10  «  BIT  MAP  INDEX 

!  Rll  *  COUNTER  POR  BIT 

!  P.12  *  BIT  MAP  WORD 

t  R13  «*  WORKING  REGISTER 

I  ft*##########*#*#**##########***######## 


LOCAL  BLKS  WORD 

IS  COMPACTED  BYTE 
FILLERS  BYTE 


ENTRY 

LD  BLKS ,  R0 

LDB  IS  COMPACTED,  #FALSE 
LD  R10,  #ZERO 
DO 

CP  R10,  #(MAX  POSS  G  BLKS/16) 

IF  EQ  THEN 

CPB  IS  COMPACTED,  #FALSE 
IF  EO  "THEN 

CALL  COMPACT  G 
LD  R10,  #ZERO 
LDB  IS .COMPACTED,  #TRUE 

ELSE 

LD  R3,  # GLOBAL  MEM  FULL 
RET 
FI 
FI 

LD  Rll,  #ZERO 

LD  R12,  GLOBAL  MEM  BIT  MAP(R10) 
DO 

BIT  B12,  Rll 
IF  Z  THEN 

DEC  R0,  #1 

ELSE 

LD  R0,  BLKS 
FI 

CP  R0 ,  #ZERO 
IF  EO  THEN 
LD  Rl,  R10 
MULT  RR0,  #16 
ADD  Rl,  Rll 
SUB  Rl ,  BLKS 
MULT  RR0,  #BLK  SIZE 
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ADD  El,  #GLOBAL  MEM  BASE 
LD  R0 ,  #VALID 
LD  R13,  BLKS 
DO 

ID  R12,  GLOBAL  MEM  BIT  MAP(R10) 

DO 

SET  R12,  RU 
DEC  R13,  31 
DEC  Rll,  #1 
CP  R13,  #ZERO 
IP  EQ  TEEN 

LD  GLOBAL  MEM  BIT  MAP{R10),  R12 
RET 
FI 

CP  Rll,  #Z£RO 
IP  EQ  TEEN 

LD  GLOBAL  MEM  BIT  MAP(B10),  R12 
LD  RU,  #15 
DEC  R10,  #1 
EXIT 
PI 
OD 
OD 
PI 

INC  Rll,  #1 
CP  Rll,  #16 
IP  EQ  THEN 

LD  Rll,  #ZERO 
EXIT 
FI 
OD 

INC  R10,  #1 
OD 

END  ALLOC  GLOBAL  MEMORY 


READ  PAGE  PROCEDURE 

lie**#*#*#####****#*#***#**#*##**#**##*#* 

!  PASSED  PARAMETERS 
l  R0  *  BLE  NO 

!  Rl  =  BASE  ADDR 

I  RETURNED  PARAMETER 
!  R0  *  SUCCESS  CODE 
!  LOCAL  VARIABLES 
l  R10  =  COUNTER  POR  BLOCS  MOVE 
1  Rll  *  SIMULATED  DISS  ADDRESS 

I*##***#****?.#*#*#*****#*#****#*##****** 

ENTRY 

LDL  RR10,  #RLK.  SIZE 

MULT  RR10,  R0 

ADD  Rll,  #DISK  MEM  BASE 
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LD  H10,  #MAX  PAGE  SIZE 
LDIR  <?R1,  3Ril ,  Rl0 
LD  R0,  #VALID 
END  READ  PAGE 


£ 


!  PASSED  PARAMETERS 
l  R0  »  BLK  NO 

t  R1  *  FROM  BASE.ADDR 

!  RETURNED  PARAMETR 
l  R0  »  SUCCESS. CODE 
l  LOCAL  VARIABLES 
I  R10  «  COUNTER  FOR  BLOCK  MOVE 
I  Rll  -  SIMULATED  DISK  ADDRESS 

.frjJ^lMl********************************* 


entry 

LDL  RR10,  #BLK_SIZE 
MULT  RR10,  R0 
ADD  Bll»  SDISK.toM.BASE 
LD  R10,  #MAX. PAGERS  I ZE 
LDIR  OR11,  OR1 »  R10 
LD  R0«  #VALID 
END  WRITE  PAGE 


READ  SEGMENT  PROCEDURE  _  ^ 


PASSED  PARAMETERS 

R0  *  PAGE  TABLE..  IOC  (BLK.#) 
R1  =  MEMORY  ADDR 
RETURNED  PARAMETER 
R0  =  SUCCESS  CODE 


LOCAL  VARIABLES 

R2  ■  INDEX  FOR  PAGE JTABLE_ ARRAY 


R10  *  COUNT  FOR  BLOCK  MOVE 

Rll  *  DISK  BLK  #  CONV  TO  MR*  ADDR 

R13  »  DISK’ ADDRESS 


i 


ENTRY 

LDL  RR10,  #BLK_SIZE 

MULT  RR10,  R0 

ADD  Rll,  #DISK  MEM_BASE 

LD  R2,  #ZERO 

DO 

LD  R10»  #MAX  PAGE  SIZE 
LD  R13,  R11(R2) 

MULT  RR12,  #BLK_S IZE 
ADD  R13,  #DISK_MEM_BASE 
LDIR  3R1,  0R13,  R10 
INC  R2,  #1 
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CP  R2,  #MAX  PAGE  SIZE 
IP  EQ  THEN 
EXIT 
II 

ID  R0,  R11(R2) 

CP  R0,  &ZERO 
IF  EQ  TEEN 
EXIT 
II 
OD 

ID  R0,  #7ALID 
END  READ  SEGMENT 


WRITE_SEGMINT  PROCEDDRE 

|  **#*****«$«:M*********#**V*>t<#***>****$**  { 

!  PASSED  PARAMETERS  t 

I  R0  -  PAGE  TABLE  LOC  (BLX  #)  t 

I  R1  -  MEMORY  ADDR  ! 

1  RETURNED  PARARETER  1 

!  Re  *  SUCCESS  CODE  ! 

I  LOCAL  VARIABLES  ! 

!  R10  *  PAGE  TABLE  ARRAY  INDEX  t 

J  Rll  »  DISK* BLX  NO  CONV  TO  MEM  ADDR  ! 

!  ni3  -  DISX‘ADDR  ! 

I  *4******4mO*4^*****iM*********«*******«**  I 

ENTRY 

LDL  RR10,  #BLX  SIZE 

MULT  RR10,  R0 

ADD  Rll t  #DISK  MEM  BASE 

LD  R2,  #ZERO 

DO 

LD  R10,  #MAX  PAGE  SIZE 
LD  R13,  R11(R2) 

MULT  RR12,  #BLK  SIZE 
ADD  Rl3f  #DISK  MEM  BASE 
LDIR  9K13,  9RlT  R10 
INC  R2,  #1 

CP  R2,  #MAX  PAGE  SIZE 
IF  EQ  THEN 
EXIT 
FI 

LD  R0,  R11(R2) 

CP  R0,  #ZERO 
IF  EQ  THEN 
EXIT 
FI 
OD 

LD  R0,  #VALID 
END  WRITE  SEGMENT 
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READ  DISK  BIT  MAP  PROCEDURE 
!  RETURNED  PARAMETERS 

;  Re  -  success  code 
!  LOCAL  VARIABLES 
!  R10  »  DISK  BIT  MAP  BUEE  ADDR 

!  Rll  *  COUNTER  FOR  BLK  MOVE 
t  R13  »  BIT  MAP  DISK  ADDR 

ENTRY 

LD  R10,  #DISK  BIT  MAP 
LD  R13,  #DISK'BIT~MA?  LO^ 

CLR  R12 

MULT  RR12,  #BLK  SIZE 

ADD  R13,  #DISK  MEM  BASE 

LD  Rll,  #(MAX  POSS"D  B1KS/16) 

LDIR  <?R13,  $R10,  Rll” 

LD  R0,  #VALID 
END  READ. DISK. BIT.MAP 

WRITE  DISK  BIT  MAP  PROCEDURE 

|*i#***iita**S****#3t********************* 

!  RETURNED  PARAMETER 
!  R0  *  SUCCESS  CODE 
!  LOCAL  VARIABLES 
!  R10  «  DISK  BIT  MAP  BUEE  ADDR 

!  Rll  «  COUNT SR  fOR  BIT  MAP 
!  R13  *  BIT  MAP  ADDRESS 

1**+*+**+*+++*+#$++**+++*#**$+*+#++++#+* 
ENTRY 

LD  R10,  *DISK  BIT  MAP 
LD  R13,  #DISK"BIT"MAP  LOC 
CLR  R12 

MULT  RR12,  #BLK  SIZE 

ADD  R13,  #DISK  MEM  BASE 

LD  Rll,  #(MAX  P0SS"D_BLKS/16) 

LDIR  OR10,  OR  13,  Rll 
LD  R0,  #VALID 

END  WRITE. DISK. BIT.MAP 

SEARCH  DISK  BIT  MAP  PROCEDURE 

!  PASSED  PARAMETER 
t  R0  *  START  SRCH  BLK  # 
t  RETURNED  PARAMETERS 
!  R-0  «  SUCCESS  CODE 

!  R1  *  FREE  BI.K  # 

!  LOCAL  VARIABLES 
!  R10  *  BIT  COUNTER 

!  Rll  =  BIT  MAP  INDEX 

!  R12  =  BIT  MAP  WORD 
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|  ft*####*#*######*#*##**####*##***##’!'##*#  J 

ENTRY 
CL2  R10 
ID  Ril,  R0 
DIV  RR10,  #16 

!  R10  =  REM,  Rll  »  QUO*  l 

DO 

ID  R12,  DISK  BIT  MAP (Rll) 

DO 

BIT  R12,  R10 
IF  Z  THEN 

SET  R12,  R10 

ID  DISK  BIT  MAP (Rll),  R12 
ID  HI,  Rll 
MULT  RR0,  #16 
ADD  Rl,  R10 
ID  R0,  #VALID 
RET 
FI 

INC  R13,  #1 
CP  R10,  #16 
IF  EQ  THEN 

ID  R10 ,  #2£RO 
EXIT 
FI 
OD 

INC  Rll*  #1 

CP  Rll,  #(MAX  POSS  D  BLKS/16) 

IF  EQ  THEN 

ID  R0,  #SEC  STOP.  FULL 
RET 
FI 
OD 

LD  R0,  #VALID 
END  SEARCH  DISK  BIT  MAP 


CLEAR.DISK.BIT  MAP  PROCEDURE 

I  ft*#*#*##****#*#######**#*#*##*##**#****# 

!  PASSED  PARAMETER 
!  R0  *  BLK  NO  TO  CLEAR 
!  LOCAL  VARIABLES 
i  R10  =  BIT  COUNTER 

!  Rll  *  BIT  MAP  INDEX 

!  R12  *  BIT  MAP  WORD 

| *#*#**#**##****M*#**##****#*#****#****# 

ENTRY 
CLR  R10 
LD  Rll,  R0 

DIV  RR10,  #16 
!  R10  =  REM,  Rll  =  QUOT  ! 


LD  R12,  DISK  3IT  MAP  (HU) 
RES  R12,  R10~ 

ID  DISK  BIT  MAP(Rll),  R12 
END  CLEAR  DISK  BIT  MAP 


MEMORY  MOVE  PROCEDURE 

!  PASSED  PARAMETERS 
!  R0  *  TO  ADDR 
!  R1  «  FR&M  ADDR 
!  R2  »  SIZE"IN  BITES 

]**j^*********************#*##********** 

ENTRY 
CLR  R12 
LD  R13,  R2 
RR  R13,  #1 
LD  R12,  R0 
LDIRB  0R12,  OR1 ,  R13 
END  MEMORY  MOVE 


GET  UN IQ  ID  PROCEDURE 

|  *******)MMt>>M***************************  { 

!  RETURNED  PARAMETERS  ! 

!  R0  «  SUCCESS  CODE  ! 

!  HI  -  UNIQUE  ID  1 

!  NOTE:  WILL  BE  STORED  ON  SEC  STOR  ! 

]  **********>M***************************  l 

LOCAL  WORK  SPACE  BLK  ARRAY  [MAX  PAGE  SIZE  WORD] 
UNIQ'ID  WORD 

ENTRY 

LD  R0,  #SYSTEM  DATA  LOC 
LD  Rl,  #WORK  SPACE  BLK 

CALL  READ  PAGE- 
CP  R0,  #VALID 

IF  NE  THEN 

RET 
FI 

LD  R10,  #ZSRO  !  UNIQ  ID  INDEX  ! 

LD  R13,  WORK  SPACE  BLK(R10 ) 

LD  UNIQ  ID,  R13 
INC  R13,  #1 

LD  WORK  SPACE  BLK(R10 ) ,  R13 
LD  R0,  ^SYSTEM  DATA  LOC 

LD  Rl,  #WORK  SPACE  BLK 

CALL  WRITE  PAGE 
LD  Rl,  UNIQ  ID 
END  GET  UNIQ  ID 
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MAINLINE  PROCEDURE 
ENTR7 

CALL  ALLOC  LOCAL  MBMORT 
CALL  BBUG 
END  MAIN  LINE 
END  M  MGR  2 
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APPENDIX  C  -  SWAP.IN  PLZ/ASM  CODE 
MEM_MGR  MODULE 

!  *  *  *  *  VERS.  1.0  *  *  *  *  ! 


CONSTANT 


FALSE 

s  0 

TRUE 

*  1 

AVAILABLE 

»  0  ! 

ACTIVE 

*  1  1 

ZERO 

*  0 

NULL 

*  3(0000 

NULL  PAGE 

a  0 

HBUG” 

*  3A900 

MONITOR 

-  30 59 A 

1  SUCCESS  CODES 
INVALID  :*  2 
VALID  :*  1 
POUND  :*  2 
NOT  POUND  2 
SWAPPED. IN  :*  4 
SWAPPED  OUT  :*  £ 
SEG  ACTIVATED  :*  t 
SEG’ DEACTIVATED  :*  7 
SEG**  CREATED  :=  € 
SEG’ DELETED  < 
LEAP  SEG  EXISTS  :«  3 
NO  LEAP  EXISTS  :*  1 
G  AST  FULL  i*  3 
L“AST"FULL  :«  3 
IN  LOCAL  MEMORY  :=  3 
NOT  IN  L&CAL  MEM  :*  3 
LOCAL  MEMORT’FULL:*  3 
GLOBAL  MEM  PULL  :  =  3 
VIRTUAL  CORE  FULL:*  3 
DUPLICATE  ENTRY  :*  3 
NO  CHILD  TO  DEL  :*  2 
SEC  STOR’PULL  :*  2 
DISK  ERROR  :*  2 
ALIAS  DOES  NOT  EXIST 


:=  23 


ATTRIBUTE  MASKS 
READ  MASK 
WRITE  MASK 


:*  3(2)11111110 
:=  %(2)00000001 


r  V 

K 


CHANGED  MASK 

•  55 

2(2)01000000 

IN  MEMORY  MASK 

;  = 

2(2)00000100 

CLEARED 

•  X 

0 

!  CLEAR  ATTR  ! 

! 

AUTHORIZED  ACCESS 

! 

READ 

*3 

0 

WRITE 

*« 

1 

EXECUTE 

;  a 

2(2)00001000 

! 

G  AST  FLAG  BITS  FIELD 

MASKS 

t 

WRITABLE  MASK 

2(2)00000010 

WRITTEN.fiASK 

!» 

2(2)00000100 

! 

DESIGN  PARAMETERS 

1 

BLK  SIZE 

:» 

128 

NO  5F  PROCESSORS 

!■ 

1 

MAX  DBR  NO 

S* 

4  ! 

EVEN  NO. 

OF  DBR  #'S  1 

G  AST  LIMIT 

•  * 

16 

I  MAX  ENTRIES  IN  G  AST  ! 

L~AST"LIMIT 

:■ 

16 

!  MAX  ENTRIES  IN  LlAST  ! 

MAX  ENTRY  NO 

:* 

21 

I  SIZE  OF 

ALIAS  TABLE  ! 

NO  §EG  DESC  REG 

:■ 

8  l 

NO.  OF  SEGMENT/PROCESS  ! 

FST  POSS  FREE  BLK 

:■ 

1 

TYPE 

ADDRESS  WORD 

ALIAS  READER  RECORD  [ 

SEG  PAGE  TABLE_LOC  WORD 
PAB'ALIAS  TABLE  LOC  WORD  ] 


SEG.DESC.REG 


RECORD  [ 

BASE  ADDR  ADDRESS 
LIMIT  BITE 

ATTRIBUTE  BYTE  ] 


ALIAS 


RECORD  C 

UNIQUE  ID  WORD 

CLASS  '  WORD 

SIZE  WORD 

PAGE  TABLE  LOC  WORD 
ALIAS  TABLE  LOC  WORD  ] 


MMU 


RECORD  [ 

SDR  ARRAY  [NO  SEG  DESC  REG 
SEG"DESC  REGj 
BLKS  USED  WORD 

MAX  BLKS  WORD] 


G.AST.REC 


RECORD  [ 
UNIQUE  ID1 
GLOBAL" ADDR 
!  ONLY  ONE  PROCESSOR  ! 


WORD 

ADDRESS 
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PROCESSORS  L  ASTE  NO  WORD 
!  WRITTEN  BIT  AND  WRITABLE  BIT  ! 

PL AG  BITS  WORD 

G  ASTE  NO  PAR  WORD 
NO  ACTIVE’ I NJ1EMORT  WORD 
NO  ACTIVE  DEPENDENTS  WORD 
PAGE  TABLE  LOCI  WORD 
SIZE!  ~  WORD 
ALIAS  TABLE  LOCI  WORD 
SEQUENCER  WORD 

INSTANCE1  WORD 

INSTANCE2  WORD  3 

L  AST  REC  RECORD  [ 

MEMORT  ADDR  ADDRESS 

SEGMENT  NO  ACCESS  AUTB  ARRAT 
[MAX^DBR.NO  'BYTE]  1 
HANDLE  RECORD  [ 

UNIQUE  ID2  WORD 
H_ INDEX  WORD  ] 


GLOBAL 

!$SECTION  G.DATA  ! 

G_AST  ARRAT  [G_AST_LIMIT  G_AST„RBC] 

G^AST  LOCK  BITE 

DISK_BIT_MAP_ LOCK  BITS 

l  ^SECTION  L.DATA  ! 

MMU  IMAGE  ARRAT  [MAX  DBR  NO  MMU] 

L„A§T  ARRAT  [L  AST  LIMIT  L  AST  REC] 

ALIAS  TABLE  RECORD  ["HEADER  ALIAS  HEADER 

ALIAS  ENTRT  ARRAT 
[MAX_BNTRT  NO  ALIAS]  ] 
DISK  BIT  MAP  BUFP  ARRAT  [6  BYTE] 

PAGE  TABLE  BUFFER  ARRAT  [BLK  SIZE  BTTE] 

EXTERNAL 


ALLOC  LOCAL  MEMORT  PROCEDURE 
ENTRY 

END  ALLOC  LOCAL  MEMORY 


READ  SEGMENT  PROCEDURE 
ENTRY 

END  READ  SEGMENT 
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FREE  LOCAL  BIT  MAP  PROCEDURE 
ENTRY  ‘ 

END  FREE  LOCAL  BIT  MAP 


ALLOC  _  GLOBAL_MEMORT  PROCEDURE 
ENTRY 

END  ALLOC_GLQBAL_MEMORY 


MOVE  TO  GLOBAL  PROCEDURE 
ENTRY 

END  MOVE„TO_GLOBAL 

SIGNAL  OTHER  MEMORY  MANAGERS  PROCEDURE 
ENTRY 

END  S IGNAL.OTHER.MEMORY ^MANAGERS 
INTERNAL 

UPDATE  MMU  IMAGE  PROCEDURE 

ji|^****iita*4^****4^******************#** 

!  PASSED  PARAMETERS 
l  R0  ■  DBR  # 

!  R1  -  SEGMENT  # 

!  R2  »  ADDR 

I  R3  =  ACCESS 

!  R4  «  LIMIT 

I  LOCAL  VARIABLES 
i  R10  *  WORKING  REGISTER 

!  R13  »  WORKING  REGISTER 

j**#*****#4^#*****#***iM'%**«*********** 

ENTRY 

LD  R10 ,  #MMU  IMAGE 
LD  R13 ,  #SIZE0F  MMU 
MULT  RR12,  R0 
ADD  R10t  R13 

LD  R13,  #SIZEOF  SSG  DESC  REG 


;  » 

MULT  RR12,  HI 

!  At 

ADD  R10,  R13 

LD  OR10,  R2 

•  .l\„ 

v? 

INC  R10 ,  #2 

LDB  OR  10,  RL4 

111. 

INC  R10,  #1 

LDB  RL4,  OR10 

(  # 

, « 

CPB  RL3,  #EXECUTE 

IF  EQ  THEN 

,  , 

ANDB  RL4,  #%(2)11110111 

4  • 

ELSE 

7  . 

ANDB  RL4,  #*(2)11111110 

i  ' 

f 

FI 

K 

i  £ 
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ORB  RL4,  RL3 
LDB  OR10,  RL4 
RET 

END  OP DATE_MMU_ I MAGE 


UPDATE. L  AST.ACCESS  PROCEDURE 

j*******^***********#**#**#**#******** 

!  PASSED  PARAMETERS 
!  R0  »  INDEX 

l  R1  -  ACCESS  AUTE 

!  R2  -  D3R  # 

l  LOCAL  VARIABLES 
!  R5  -  WORKING  REGISTER 

!  R7  »  WORKING  REGISTER 

ENTRY 

LD  R5,  #L  AST 

LD  R7,  #SIZEOP  L  AST  REC 

MULT  RR6,  R0 

ADD  R7,  #2 

ADD  R7f  R2 

ADD  R5,  R7 

LDB  RL3,  0R5 

CPB  RL1,  #WRITE 

IF  EQ  THEN 

ORB  RL3,  #%(2 >10000000 
LDB  0R5,  RL3 

ELSE 

ANDB  RL3,  #%(2)01111111 
LDB  OR5,  RL3 
FI 
RET 

END  UPDATE. L_AST_ACCESS 

CHECK  LOCAL  MEMORY  PROCEDURE 

}*$****#$*#********##*#******#********* 
!  PASSED  PARAMETERS 

!  R0  «  INDEX 

!  RETURNED  PARAMETER 
I  R0  =  TEST 

!  LOCAL  VARIABLES 
l  R2  «  I 

!  R3  *  SEG  NO 

I  RH3  »  ATTRIBUTES 

!  R10  «  A DDR  OF  MMU  IMAGE. SDR [SEG#] 

!  Rll  =  ADDR  OF  L  AST [R0] .SEG/ACC[I] 

!  R12 ,13  =  WORKING  REGISTERS 

I************************************** 

ENTRY 
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LB  R2,  #ZEBO 
BO 

CP  R2,  #MAX  BBR  NO 

IP  EQ  THEN 

LB  R0f  #NOT  IN  LOCAL  MEM 

RET 
FI 

LB  Rll,  #L  AST 

LB  R13,  #SIZEOF  L  AST  KEC 

MULT  RR12,  R0 
ABB  Rllt  R13 

ABB  Rll,  #2  1  SEGMENT  NO  OFFSET  l 

ABB  Rll,  R2 
LBB  RL3,  OR11 
CLRB  RH3 

ANBB  RL3,  %(2)01111111 
CPB  RL3,  #ZERO 
IF  NE  THEN 

LB  R10,  #MMU  IMAGE 
LB  R13,  #SIZEOF  MMU 
MULT  RR12,  R2 
ABB  R10,  R13 
ABB  R10,  R3 

ABB  R10,  #3  t  ATTRIBUTES  OFFSET  ! 

LBB  RH1,  OR10 

ANBB  RH1,  #IN  MEMORY  MASS 

CPB  RH1,  #ZERO 

IF  NE  THEN 

LB  R0,  #IN  LOCAL  MEMORY 
RET 
FI 
FI 

INC  R2,  #1 
OB 

ENB  CHECK_LOCAL_MEMORY 


CHECK_MAX_ VIRTUAL. CORE  PROCEBURE 

J  PASSES  PARAMETERS 

I  R0  =  BBR  # 

t  R1  *  BLKS 

!  RETURNEB  PARAMETER 
!  R0  =  SUCCESS  COBE 

!  LOCAL  VARIABLES 
t  R10.R12  =  WORKING  REGISTERS 

ENTRY 

LB  R10,  #MMU  IMAGE 
LB  R13,  #SIZEOF  MMU 


MULT  RR12,  R0 
ADD  R10,  R13 

LD  R13,  #SIZEOF  SEG  DESC  REG 

MULT  RR12,  #N0  SEG  DESC  REG 

ADD  R10,  R13 

LD  R12  *  OR10 

ADD  R12,  HI 

INC  R10,  #2 

CP  R12,  OR10 

IP  GT  TEEN 

SUB  R12,  R1 

LD  R0,  VIRTUAL  CORE  PULL 

ELSE 

LD  R0,  #VALID 
PI 

DEC  R10t  #2 
LD  0R10,  R12 
RET 

END  CHECK  MAI  VIRTUAL  CORE 


SWAP  IN  PROCEDURE 


!  PASSED  PARAMETERS 

!  R0  «  INDEX 

t  R1  *  DBR  # 

!  R2  *  ACCESS 

!  RETURNED  PARAMETER 
l  R0  »  SUCCESS  CODE 
1++**++#**#**+*+++*+**++*++++**+++*++*+ 


LOCAL  INDEX  WORD 

DBR  NO  WORD 

ACCESS  WORD 

G  AST  BASE  ADDRESS 

ENTRY 

LD  INDEX,  R0 

LD  DBR  NO,  R1 

LD  ACCESS,  R2 

LD  R5,  #G  AST 

LD  R13,  #SIZEOF  G  AST  REC 

MULT  RR12,  R0 

ADD  R5,  R13 

LD  G  AST  BASE,  R5 

ADD  R5,  #16  !  SIZE  OPPSET  J 

CLR  R6 

LD  R7,  (?R5 


DIV  RR6,  #BLK  SIZE 
LD  RS,  R7 

DEC  R5,  #12  i  L  AST  INDEX  OFFSET  ! 


LD 

R7, 

0R5 

LD 

R0, 

HI 

LD 

HI, 

R6 
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CALL  CHECK  MAI  VIRTUAL  CORE 
CP  R0,  #VIRTUAL  CORE  IULL 
IF  EQ  THEN 
RET 
FI 

INC  R5,  #4  !  NO  ACTIVE  IN  MEMORY  OFFSET  ! 

INC  0R5,  #1 
ID  R6,  0R5 
CP  ACCESS,  #WRITE 
IF  EQ  THEN 

DEC  R5,  #4  !  OFFSET  TO  FLAO  BITS  ! 

LD  R4,  0R5 

OR  R4,  #WRITABLE  MASK 
LD  C»R5,  R4 
FI 

LD  R0,  R? 

CALL  CHECK  LOCAL  MEMORY 
AND  R4,  #WRITABLE  MASK 
CP  R4V  #0 
IF  NE  THEN 
CP  R8,  #1 
IF  GT  THEN 

CP  R0,  #IN  LOCAL  MEMORY 
IF  NE  THEN 
LD  R0 ,  R6 

CALL  ALLOC  LOCAL  MEMORY 
CP  R0,  #LOCAL. MEMORY  FULL 
IF  EQ  THEN 
RET 
FI 

LD  R9,  R1 

INC  R5,  #8  !  PACE  TABLE  LOC  OFFSET  l 

LD  R0,  0R5 
CALL  READ  SEGMENT 
CP  R0,  #VALID 
IF  NE  THEN 
LD  R0 ,  R9 
LD  Rl,  RS 

CALL  FREE  LOCAL  BIT  MAP 
UET 


FI 

LD  R10,  #L  AST 

LD  R13,  #SIZEOF  L  AST  REC 

MULT  RR12,  R7 

ADD  R10,  R13  IMEMORY  ADDR  OFLOET  INTO  L  AST! 
LD  0R10,  R9 


ELSE 


LD  R10,  #L  AST 
LD  R13,  #SlZEOF  L  AST  REC 
MULT  RR12,  R7 
ADD  R10,  R13 


159 


LB  R9 t  OR10 


ELSE 


LB  B8,  R0 
LB  R5,  G  AST  BASE 

INC  R5,  #2  ~!  GLOBAL  ADBR  OFFSET  ! 
LB  R12,  OR 5 
CP  R12,  #NULL 
IF  EQ  THEN 
LB  30 ,  R6 

CALL  ALLOC  GLOBAL  MEMORY 
CP  R0 ,  #GLOBAL  MEM  FULL 
IF  EQ  THEN 
RET 
FI 

LB  B9 ,  R1 

CP  R8,  #IN  LOCAL  MEMORY 
IF  EQ  THEN 
LB  R0|  R? 

INC  R5,  #14  !  SIZE  OFFSET  ! 

LB  R2 ,  OR 5 

Call  MOVE  TO  GLOBAL 

CP  R0 ,  #VALIB 

IF  NE  THEN 


FI 

ELSE 

LB 


LB  R0,  R1 
LB  Rl,  INBEZ 

CALL  SIGNAL  OTHER  MEMORY  MANAGERS 
CP  R0,  #VALIB 
IF  NE  THEN 
RET 
FI 
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ELSE 

LB  35  ,G  AST  BASE 

ABB  R5,  #2  '!  GLOBAL  ABBR  OFFSET 

LB  R9 ,  OR 5 


FI 

FI 

LB 

R0, 

BBR  NO 

LB 

R10, 

#l”ast 

LB 

R13, 

#si ZEO 

MULT  RR12,  R? 

ABB 

R10 

f  R13 

ABB 

R10 

,  R0 

INC 

R10 

,  #2 

LBB 

RL1 

,  OR10 

LB 

R2f 

R9 
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LD  A3,  ACCESS 
LB  R4,  R6 

CALL  UPDATE  MMU.IMAGE 
LB  R0,  R? 

LB  El,  ACCESS 
LB  R2,  DBR_NO 
CALL  UPDATE  L  AST_ACCESS 
LB  R0,  #SVAPPED_IN 
END  SVAP.IN 

MAIN  LINE  PROCEDURE 
ENTRY 

CALL  SVAP..IN 
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